Your article is great. The examples of functional and non-functional uses of Rust were neat. I've been practicing by doing the Rust track on exercism.io and, by comparing my solutions to others', I always get impressed by how equally performant those two versions are (at small programs at least).
Rust is an interesting language, although I haven't really had the time to really sit down and play with it (just switched jobs to become a mobile developer while knowing no Swift/Obj-C and not much Java, so I've got my hands full for at least a few weeks).
I've been watching Rust on that Benchmarks Game site for a while — it's been interesting to see it go from worse than Java a year or so ago to competitive with C++. It was slightly beating C++ for a couple days, although just recently C++ took its biggest lead in a while[0]; I think they upgraded the GCC version they were using.
Anyway, I'm very curious whether it ultimately turns out that, as advertised, Rust's performance characteristics really are as good or better than C++'s[1].
[1] The "Benchmarks Game" site very fairly specifies the algorithm that must be used for each benchmark — many of them say data must be operated on sequentially, so IMO Rust is getting a bit of an unfair advantage if the compiler is able to be particularly aggressive at autovectorizing it.
OTOH that is a nice real-world speedup, and anything else that's implemented with LLVM or GCC also has access to that optimization, so YMMV.
> Anyway, I'm very curious whether it ultimately turns out that, as advertised, Rust's performance characteristics really are as good or better than C++'s[1].
From my limited experience, Rust's performance is comparable to C++ throughout, with the added safety guarantees that Rust is known for.
> I've been watching Rust on that Benchmarks Game site for a while — it's been interesting to see it go from worse than Java a year or so ago to competitive with C++
To be clear, Rust-the-language has not sped up significantly in the past year. It's just that a few dedicated people decided to try to win the benchmarks game strictly for PR purposes [0].
Chances are, for very algo-heavy (i.e. unrealistic) workloads, there are two ways to write it in Rust - fast and safe or very fast and unsafe. (e.g. one can disable bounds checking and get maybe a 2% speedup).
All this really serves to show is how artificial the benchmarks are.
Perhaps smitherfield actually was talking about the overall relative performance of "Rust [programs] on that Benchmarks Game site".
To say something about whether Rust-the-language-implementation was building faster executables wouldn't we compare the same Rust programs built with different Rust versions (not compare Rust programs against Java or C++ programs).
Match-up measurements of the same programs, from the 1st June 2015 and 1st June 2016 data files, like this:
In general, safe code should t always be slower than unsafe; as said below, if stuff is slower, it's a bug. The relationship is more complex than unsafe == faster.
I decided to try out rust in a game jam hosted at my university a few weeks ago. It was a great learning experience, which is to say that it was incredibly frustrating in a good way.
I didn't haha. I spent probably a good 3 hours trying to figure out why I couldn't mutuably store a value I got out of a hashmap. It was fun though :) a throwback to when I was learning c and didn't get pointers.
The learning pain is comparable to C pointers when you first see them haha. Funny thing is that after getting used to the borrow checker and other nice things of the language, its sad to go back to the languages I use at work.
I didn't see it until it was mentioned here.
I can't seem to delete this discussion. So I added the original link here. Please head there.