After many years of waiting, version 1.0 of the Rust programming language has finally been released. The Rust home page describes Rust as "a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety."
Thanks to the hard work of noted Rust core team members Yehuda Katz and Steve Klabnik, Rust is now poised to become a serious competitor to established systems programming languages like C and C++.
The announcement has brought much jubilation to the followers of Rust, who have been eagerly awaiting this milestone release for so long. With only 1,940 open issues and over 11,500 issues already closed, Rust is finally ready for users to build fantastically reliable software systems using it.
(Score: 1, Interesting) by Anonymous Coward on Saturday May 16 2015, @03:55AM
You gain modules and their related compile time improvements, better option/union type support with pattern matching, compiler enforced thread safety/no data races, more robust templates with better errors, not needing header files, simpler syntax etc.
Personally I like the more expression oriented style, memory safety and provable lack of memory leaks and dangling pointer bugs. It keeps the main feature of C++ I care about (the ability to call C and C++ code, and be called by it). Rust is a decent language to write a module for an otherwise C or C++ project in if you want some of its features.
(Score: 1, Interesting) by Anonymous Coward on Saturday May 16 2015, @05:19AM
You gain modules and their related compile time improvements
The module system is nowhere near as flexible as the options that C++ allows for, both file-based and in terms of namespaces and classes. Besides, all modern C++ compilers have supported precompiled headers for ages, which drastically improves compilation time.
better option/union type support with pattern matching
After using this in Haskell and Scala, it's useful, but not that useful. Much of this can be done using C++'s templates well enough.
compiler enforced thread safety/no data races
This is only as good as the language implementation is. Rust is a language with a single implementation with almost 2,000 open issues. If the implementation is so broken, how can I be sure that whatever the compiler is enforcing is being done correctly?
more robust templates with better errors
I don't think that's true. C++'s templates are quite robust and powerful already. Rust doesn't really improve on that. Modern C++ compilers, especially Clang, offer very comprehensible and useful template error messages these days. Even GCC is getting better.
not needing header files
Header files aren't a bad thing. They're quite powerful.
simpler syntax
Rust's syntax is very similar to C++'s. C++'s syntax is generally quite straightforward. Even C++'s semantics are quite easy, compared to stuff like Rust's ownership semantics.
In closing, it has taken Rust years to get to this point, and there's not much to show for it. I don't think we'll see any miracles that suddenly allow it to become any better than it already is (or isn't).
(Score: 1, Interesting) by Anonymous Coward on Saturday May 16 2015, @05:57AM
Regarding your comment on thread safety: the threading/sync stuff is actually a library feature (they rewrote it to be such recently). Rust's owner ship semantics are enough to make that possible. Fixing the few remaining holes in the compiler soundness checks should be easier than fixing even one large C++ project, and it will fix all the rust projects.
As for templates: personally I like that that templates only validate once: you can't have a compile error in a particular instantiantion, and its clear what types are legal to paramaterize it with.
If you like header files and get along well with precompiled headers, stick with your c++. I'm just happy I can call your code from rust :)
C++ is a great language if you are a badass, but I'm much rather hire devs to write me rust than C++ where there is so much less shit they can get wrong. I could trust interns to write secure multithreaded code thats performant (Don't do that in most languages). Its also far harder to break when refactoring (The completeness guarantees on match are one such example).
(Score: 0) by Anonymous Coward on Saturday May 16 2015, @01:03PM
Rust's ownership semantics will leave you scratching your head, and then once you finally understand how it's supposed to work, you'll still end up fighting the compiler.
(Score: 4, Insightful) by maxwell demon on Saturday May 16 2015, @07:22AM
I disagree with this. It shows on many places that the C syntax on which it builds simply wasn't made for it, and some added syntax also is not exactly helpful.
Consider the following code, and think about why you need the bolded keywords:
template<typename T, typename U> typename T::value_type f(T t, U u)
{
T foo(U()); // C++'s most vexing parse; do you see what's wrong?
return foo.template frobnicate<int>(u);
}
Don't get me wrong, C++ is the best language I know. But its syntax is not its strong point.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by tonyPick on Saturday May 16 2015, @08:01AM
Templates can lead to some really odd cases: See also this blog post [reverberate.org].
Responding to the GP point: C++ syntax can be straightforward provided you only use a subset of the features; however nobody can agree on what that subset is, and as soon as you use someone else's code/library then the complexity explodes. The C++ standards approach of "throw another feature into the mix" isn't helping any.