Path to Rust – A practical introduction | Hacker News Reader

Path to Rust – A practical introduction

thesquareplanet.com

136 pointssargas20 comments

The article itself points to a HN discussion: https://news.ycombinator.com/item?id=11774850

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.

It was, in fact, originally posted at https://news.ycombinator.com/item?id=11773332 by me (the author), but that post never got much attention :p

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).

Thanks! Glad to hear that you found it interesting :)

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].

[0] http://benchmarksgame.alioth.debian.org/u64q/which-programs-...

[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.

Currently if Rust under performs C/C++ by a significant margin it's treated as a bug.

(The number crunching on benchmark game is done with SIMD which Rust is working on)

> 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.

[0] https://llogiq.github.io/2015/10/03/fast.html

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.

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:

    elapsed secs	program id
    4.013 => 3.780	binarytrees #1
    15.449 => 16.650	fannkuchredux #2
    5.204 => 5.588	fasta #1
    0.070 => 0.067	meteor #1
    0.050 => 0.044	meteor #2
    24.630 => 24.068	nbody #1
    1.733 => 1.743	pidigits #1
    436.686 => 288.131	threadring #1

:and then note that the measurements were made on different OS versions, probably with different LLVM versions.

>> artificial

Perhaps you wish to draw our attention to the question of "ecological validity"?

http://benchmarksgame.alioth.debian.org/why-measure-toy-benc...

http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

>> It's just that a few dedicated people decided to try to win the benchmarks game strictly for PR purposes [0]. <<

Perhaps you should check if the programs mentioned in that blog post are actually shown on the benchmarks game website :-)

(Also check if those tasks contribute to the summary comparisons and charts.)

>> many of them say data must be operated on sequentially

I don't think so.

Previous (fruitful) discussion here: https://news.ycombinator.com/item?id=11774850

The article even has a link to that previous discussion right at the top of it.

I just saw the link on to the first HN discussion. I don't what to divide the conversation into two HN posts. How do I proceed?

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.

That's a good way to get into the language, as long as you have someone to guide you through the borrow checker during the jam.

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.

Reply on news.ycombinator.com