This is a point release that they don't need to do - on the grounds that it's not a bad time to do one, but it should help in the future to do point releases quickly if there is a real need to (security, etc).
There's a commitment in the rust team to making life really really good for developers, and I appreciate that a lot.
Even these, which obviously effected others, didn't effect my code. Cudos to the Rust team for being on top of this!
Date: Sat Aug 22 11:45:08 2015 -0700
Is Rust "mature" enough to start to dabble with and actually put down some hours into (and thus replace C in my plan)? Only hobby projects so far.
For lower level stuff Rust is a better option. Better productivity, equal performance, much higher safety.
Unless you have specific needs that require Java/C of course.
Does anybody have experiences to share using Rust like this?
I don’t know how things stand in the embedded Rust camp, however.
So why would you choose Rust? If you need to use C++, because you need performance, or low-level access to memory, or any other reason, then you should choose Rust instead, because it's better for all the reasons listed above. The biggest strike against Rust compared to C++ is library support--people have been writing C++ and C libraries for decades, and Rust is a new language, so it won't have the same level of support.
It's partly because of the memory safety features. There have been quite a few people I've noticed coming from languages like Ruby and Javascript and being successful. Whereas I think C and/or C++ might have been more challenging, again b/c of memory safety (GC's are a lovely thing to rely on, until they get in your way). The compiler offers a huge advantage here, because while it is true that it is much more restrictive than other languages, it also almost guarantees that your code is correct.
As an old C hack, with bad memories of C++, and a hater of the memory footprint of Java and the horribleness of the great GC pause; Rust has been a joy to learn and use. It's like bowling with the bumper rails up as an adult, and no one laughs at you (well, maybe they do, but you never throw a gutter ball!)
For the sake of hypothetical example, presume I have had a long history of involvement in some C++ libs which I associate with good times, hilarious IRC sessions, friends, and pouring love into the labor of creating them during 0300 caffeine overdoses. How could I possibly evaluate leaving this behind without such bias?
Many choices are vulnerable to silly human biases which are hard to detect. Debating C++ versus Rust seems to be tough for some, and technical arguments have a propensity for becoming circular, so here's an analogy instead.
- Imagine, (if you have no extreme attachments to the web) that we have created a new web with new protocols, software, hardware, solved most crypto issues, authentication is reliable, we created the safe and anonymous place of everyone's (some ppls) dreams. Most of the advances are wonderful and (mostly) fueled by the latest research and smart minds, but there are a few bugs. Overall, an improvement and well adopted but still needing polish. The problem? All the old content isn't there. Some amazing new experiences await, but reddit and youpn are not unless you pull up an old web browser. If you were tasked with creating new content, which web would you choose and why?
I propose devs consider following either this, or some other method to evaluate C++ vs. Rust more objectively and try to set attachments aside. If, rather than thinking "but I won't have libX", you ask "how can I implement this functionality better today", you may decide that casting off old clutter is liberating and insightful.
I hope this helps some of you.
1. The main benefit of Rust is its nearly cost-free safety guarantees. It's much harder to write code that is prone to UB with Rust than with C++. The comparison is almost silly, in fact, from that perspective. It comes with a runtime cost (e.g. drop flag checks, bounds/other memory access checks) in some cases, but for all cases other than those requiring even that last bit of performance this cost is tiny in comparison with the work the rest of the program is doing and well worth it in my opinion.
2. The primary reason for choosing it over any other language is context dependent. This leads me to my last point.
3. It would be fine to use for anything, really, but I think in the sense of "most appropriate" that you mean, it's "most appropriate" for systems programming that needs to be as fast as C++, but not necessarily melt-the-metal fast. Primarily this is because: a) it's as fast as C++ in almost all cases (and probably faster than equivalently-safe C++ in at least some cases) and b) it's much less likely I'll write code that smashes stacks, has data races, blows up memory or does a bunch of other crap that's trivial in C++ (or other languages). Even in cases where melt-the-metal fast is necessary it seems possible to do in Rust, but it just takes a lot of effort. That's deliberate on the part of the Rust developers, and it's difficult to argue against the reasoning behind it.
Where Rust might really shine is helping a new generation of programmers write performant code that is safe without having to learn by trial-by-fire.
Rust is pretty much the coolest thing ever in my opinion. It's easy and fun to write. Cargo is the best package manager ever, and makes importing library code a breeze. I've never had multithreaded code warn me when I don't lock it correctly. It's so awesome.
(wrt my Rust app, as soon as I load test and redesign the UI I'm going to share it on HN. It's pretty ridiculous and we have a lot of fun with it at work.)
- A fantastic package manager for your dependencies
- Easy build system
- A nicer language
- Memory safe
- Just as fast
- A way stronger compiler that will prevent you from making mistakes that you can make in C/C++ very easily
All in all more then enough benefits to make it worthwhile to switch unless there is a very good reason not to.
Featuring
* zero-cost abstractions
* move semantics
* guaranteed memory safety
* threads without data races
* trait-based generics
* pattern matching
* type inference
* minimal runtime
* efficient C bindings
Some things that are better as a result of things that are hard to do right in C++:
* Compiler monitors ownership of memory
* Compiler monitors ownership across threads
* Generics aren't handled as templates, and you can explicitly describe support using things like * trait bounds
* Macros are useful but need to operate on something more like the AST rather than text tokens
* A richer type system can help you express much more in the types (Rust enums)
As such, it targets essentially the same niche as C/C++.