Today we are very proud to announce the
1.0 release of Rust, a new programming language aiming to
make it easier to build reliable, efficient systems. Rust combines
low-level control over performance with high-level convenience and
safety guarantees. Better yet, it achieves these goals without
requiring a garbage collector or runtime, making it possible to
use Rust libraries as a “drop-in replacement” for C. If you’d
like to experiment with Rust, the
“Getting Started” section of the Rust book is your best bet
(if you prefer to use an e-reader, Pascal Hertleif maintains
unofficial e-book versions as well).
I tend to get annoyed by over glowing reviews of various technologies. There are always trade offs. It helps to have a good idea what those are before diving in.
http://www.viva64.com/en/b/0324/
Author called it a toy. I lost respect to his review after that sentence.
If you had actually read the review, you’d very quickly discover that “toy” is not being used as a pejorative. It’s being used to describe Rust as it actually is compared to real programming languages: it is a toy. It lacks the capabilities and functionality that we’d expect from a serious systems programming language.
Instead of knee-jerk overreactions due to you incorrectly perceiving something as an insult, next time you should calmly finish reading the entire article. Then you would know that what you thought was an insult was actually a very appropriate description.
Well this is interesting, because if the situation were reversed and Rust were the incumbent industrial language standard, don’t you think that C/C++ as a new comer would be the “toy” language for not having correctness verification built in? BTW I’m a fan of C/C++ myself, but I can still acknowledge it’s weaknesses. One of the things I like best about Rust is that in contrast to so many of the other modern languages being developed (ie particularly those that achieve correctness by being “managed”), rust brings us compile-time correctness without the tradeoffs of managed languages.
Edited 2015-05-16 17:12 UTC
I red the whole thing. He has some valid points, but his tone is not professional, and the “toy” title highlights it.
There are two main trade-offs:
1. It can be somewhat difficult to internalize the rules the borrow checker uses to determine whether to allow the code to compile in more complex cases.
2. If you want to implement something that falls outside the paradigm (eg. the Rc<T> reference-counting generic from the standard library), then you have to use unsafe {} blocks and the code inside those blocks is much closer to C in terms of what the compiler will let you screw up.
Also, as people on /r/rust/ already pointed out, that post is published by a company that makes their money selling a C/C++ static analysis tool. Not exactly an unbiased source.
Edited 2015-05-15 22:37 UTC
Yes, he even mentions it in the article trying to downplay that as a good feature in Rust, which caught my attention. In C++ it’s done with external tools which is a downside, not a benefit.
Bill Shooter of Bul,
From your link…
With this point the author is wrong…dangerously wrong. While there are some truths in there, time has proven over and over again (and again ad infinitum) that C/C++ code is dangerous. Many of the serious system vulnerabilities we see are the consequence of using languages without compile time code validation. Yes in theory humans can do this job, given sufficient time, resources, and motivation. However there’s an endless trail of evidence showing that despite having intelligent and well meaning developers hammering out our C code, year after year we still end up with swiss cheese software leaving many of our systems vulnerable to attack (*1).
This is a serious ongoing problem for all core software built in C, both proprietary and open source. It will continue to happen for as long as C is in use. C exploits are so notorious that we’ve designed techniques like ASLR to make exploits more difficult. Unfortunately this is just a bandaid for incorrect code, and doesn’t fix the core problem. Languages like rust are able to prevent data/pointer overflows, making techniques like ASLR unnecessary.
The beauty of rust is that unlike VM/managed languages, it manages to provide these checks at compile time, giving us important safety benefits without compromising on the performance and low level control that makes C desirable.
*1 A very serious attack against QEMU-based hyper-visors (affecting many cloud hosting providers) was disclosed just yesterday:
http://venom.crowdstrike.com/
I submitted an article on this but OSNews decided not to post it for some reason.
Edited 2015-05-16 01:55 UTC
that guy is smart but too religious about c/c++ to be a useful source of information on this topic
dear pope, how are the muslims today
Here’s the /r/rust/ post where they went into more detail on the shortcomings and issues with that review:
https://www.reddit.com/r/rust/comments/35pn5a/
I would point out the contention that Rust is “far from fast” in the article you linked is somewhat misguided, at least if it is based solely on the particular benchmark that was presented. I’m not saying it is incorrect, just that it is leaving out some relevant details.
If you actually look at the individual scores on that benchmark:
http://benchmarksgame.alioth.debian.org/u64/rust.php
You will notice that on most of them Rust is very close to C compiled with GCC. Faster on one, fairly close on most (within 2x), and at most 3x slower on one or two.
On one particular benchmark, however (regex-dna), it is 12x slower, which drags it’s median down considerably… It is slower on this benchmark mostly because of some acknowledged deficiencies in the Rust regex library that are being addressed:
https://github.com/rust-lang/regex/issues/66
https://github.com/rust-lang/regex/issues/68
I think in light of that saying “I sincerely hope that programmers will find a way to speed it up in time” is kind of misleading. Its already pretty damn fast already in most respects, it just has a couple of rough spots that need to be ironed out, things that don’t really have any connection to either the compiler’s behavior or the language design itself, i.e. library issues. If you look at a comparison to Java you can see what I mean – that lone benchmark sticks out like a sore thumb:
http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=rust&l…
Anyway, I’m not saying Rust will end up being faster than C or C++, but it is arguably (even with the regex problem) in the same ballpark. It don’t think saying “it is comparable to Java, Go, and Haskell regarding performance” is going to be accurate for much longer.
Edited 2015-05-16 06:08 UTC
I like the idea of Rust but every time I look into the doc it just looks ugly and very complicated. Has it any safety advantage over Nim? Nim looks much nicher and simpler compared to Rust!
I like Nim, but it’s basically a one-man show and that one man doesn’t always listen well to input. The libraries is of highly varying quality.
Rust takes more effort to learn, but it has a really amazing type system that makes it well worth it. And it has the advantage of a much larger community.
Nim is more a competitor for Go than Rust.
1. Nim is a GCed language in the same way that D is a GCed language: You can turn off the GC but, if you do, you lose so much of the standard library that it’s unfeasible.
Since you really don’t want to try to get two GCs to play nice in the same memory space, that means you can’t feasibly embed a scripting language like JavaScript or Python in Nim without rewriting them Rhino/Jython-style. It also massively constrains your ability to write libraries for use by anything with a C FFI. (Rust makes an excellent alternative to tools like Cython for offloading your hot loops to compiled code.)
2. By design, Nim’s syntax attempts to provide a more performant way to get the looser, more “do what I mean” experience of a scripting language. Rust aims for explicitness in everything for the sake of maintainability across multiple generations of contributors.
The big safety advantage Rust has over Nim is on the “humans make mistakes” side of things. (eg. Inspired by Rust’s strict, explicit type checking, the Hyper HTTP library for Rust combines Rust’s expressive type system and time inferrence to produce an API that does compile-time correctness checking for the HTTP protocol itself. (eg. It’ll catch “set headers after send” and header typos at compile time)
Edited 2015-05-16 13:33 UTC
What kind of name is “Rust”?
Were the names “Bit Rot” and “Goes Bad Over Time” taken or something?
PS: Yes I know, programmers are highly rational individuals and don’t judge technology based on the name, but the PHBs who -on some companies- have the final say, or even worse don’t even bother asking anyone who is an implementor, aren’t so.
kurkosdr,
Hahaha, your post put a picture in my head of a corporate meeting where project managers are choosing the technology to use based on how good they sound
It’s probably not that far from the truth either!
It’s explained here: http://www.evanmiller.org/a-taste-of-rust.html
Is this one that is developed by Mozilla? If so that means the new mobile browser that is co-developed by Samsung shouldn’t be too far behind.
I had the feeling I was dealing with something VERY “special” the first time I saw the syntax and language definition for Rust… unfortunately that’s “special” in the same way some Olympics are “special”.
The moment I saw they were too lazy to type the full word “function” whilst at the same time bringing back “LET” from the dark ages of ROM BASIC programming… then there’s this “boxing” garbage that reeks again of line numbered basic… fancy way of bringing us back to the hell that was DIM.
Then of course for a language that seems to want to use needlessly pointlessly cryptic reserved words, it then goes and uses a ridiculously long form “let if else” instead of the classic ternary operator style condition… MAKE UP YER BLOODY MIND!!!
The needleslly pointlessly cryptic garbage seems to extend language wide — it’s handling of conditional compilation seeming to be as intentionally obtuse and addle-minded as possible, the cargo asshattery reeking of the same “how many separate files can we create for no good reason” thinking that’s pissing all over websites when people use things like frameworks or the pain in the ASS that are ‘make’ or ‘.h” files.
I’ve not seen a programming language this malfing idiotic since I looked at Ruby or the gibberish the scripttards vomit up with the mouth-breathing idiocy known as jQuery.
But what do I know, I’m a Wirth kind of guy… who started out hand assembling my own machine language on a RCA 1802. I’d sooner hand assemble 8k of Z80 machine language than to try and debug 100 lines of C++ code; hence why I’m not convinced that this:
https://www.gnu.org/fun/jokes/unix-hoax.html
… is actually a joke.
Rust, the programming language for people who think that C++ is a little too verbose and clear for their tastes; which is a bit like making your own terrorist group because Hezbollah and the Taliban were too warm and fuzzy.
Perl 3 choose to have a baby with OCaml. Rust born.
I’m seriously appalled by Rust syntax and inclined to agree with you.
Twenty five years ago, compiler designers at least had the excuse that computers were not fast enough when designing write-only languages.
Mind elaborating on that?
Rust was designed to be less “write-only” than C++ and, in my opinion, they succeeded.
Edited 2015-05-20 15:37 UTC
Rust, the programming language by experienced C++ programmers from Mozilla who got fed up with having to either read horrendously long “your error lies somewhere in this chain of generics” error messages or track down mistakes that C++ gleefully allowed them to make because there’s no way to make the older, less compile-time-checkable stuff opt-in.
Edited 2015-05-20 15:38 UTC