Live data from Hacker News

Rust programs versus Go

benchmarksgame-team.pages.debian.net

41–50 of 209 posts

Re: Rust programs versus Go

#41
These benchmarks have many flaws.

Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar...

The binary-trees benchmark would fare significantly better in Go if it were allowed to use an arena allocator like other implementations. But its not.

This despite the fact that the Rust version literally uses one: https://benchmarksgame-team.pages.debian.net/benchmarksgame/....

I guess because its not in the stdlib in Go?

Course its not in C either, so does C use malloc? Nope. It uses a memory pool too: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Its sad that these benchmarks get used for anything. They tell you next to nothing significant.

Re: Rust programs versus Go

#42

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

Probably going to get downvoted for that, but could you recommend me some similar forums? :)

Re: Rust programs versus Go

#43
post #11

Earlier quoted context omitted.

> Rust vs. C++ benchmark the results are much more similar Not really... Try compare sources of those programs. For example spectral-norm uses OpenMP and other things that make source look really different from the one you would write in real life. Rust program looks much simpler and closer to real life code. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/…

> > the results are much more similar Parent is talking about performance, not source code

True, but that performance gained by writing code in a way which most devs wouldn't do.

Re: Rust programs versus Go

#44

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

Probably going to get downvoted for that, but could you recommend me some similar forums? :)

Reddit can be decent IMO (e.g. reddit.com/r/golang)

Re: Rust programs versus Go

#46

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

I’m the OP. I figured this post would either get tons of upvotes or flagged off the first page. The title really is a firebomb on HN lol.

But honestly I find it genuinely interesting. I’m planning to take some time to learn either rust or go this month, so comparisons like this are helpful for me. And I also appreciate the contrarian comments and discussion of the merits (or lack thereof) of the benchmarks.

Re: Rust programs versus Go

#47
This would be interesting if there were any comparison of what exactly is slower or faster between the languages or the particular implementations. This data provides a great opportunity, but it's just presented as a dumb contest.

Re: Rust programs versus Go

#48
post #3

I expect Rust to be faster than Go as a rule because of its somewhat lower level nature and cost-less "unmanaged" abstractions but I didn't expect it to be a full order of magnitude faster than Go for some benchmarks. Are the Go snippets not properly optimized or is there something else going on? I think pitting Go against Rust is somewhat inflammatory but if you look at the Rust vs. C++ benchmark the results are muc…

C/C++ are cheating by using Intel specific instructions, like _mm_cvtpd_ps. I.e. they are with hardware-specific acceleration. If standard library will be used instead, or if Rust code will be updated to use same instructions, we will see different results.

If you use a LLVM compiler, _mm_cvtpd_ps just translate to LLVM IR and is not Intel specific anymore.

Re: Rust programs versus Go

#50

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

I’m the OP. I figured this post would either get tons of upvotes or flagged off the first page. The title really is a firebomb on HN lol. But honestly I find it genuinely interesting. I’m planning to take some time to learn either rust or go this month, so comparisons like this are helpful for me. And I also appreciate the contrarian comments and discussion of the merits (or lack thereof) of the benchmarks.

I used to like Go a bit, but never did a full blown application in it, just did enough to get a feel of it. Having tried Rust recently (after not liking the idea of not having classes like in Go) I have to say I prefer Rust for several reasons.

For starters the tooling for Rust is well done. If I want to install Rust on any machine I'm on I just go to https://rustup.rs/ and go from there, then I can use rustup to update my tooling or add features to the compiled.

The other thing is the wealth of packages[0] that expand upon Cargo (Rusts build system and package manager) namely the cargo-deb package which lets me build my Rust projects directly into a Debian package.

Continuing on about tooling I have to mention that for IDE's / Text Editors: CLion w/ Rust Plugin is fantastic, but if you want something fully free the VS Code plugin is also amazing for Rust. There's a great effort towards building the Rust Language Server, which thanks to Microsoft is a generic spec that once implemented for one language can be used by any editor / IDE that supports langserver[1].

I will say depending on what you want to do with Rust there can be a bit of a learning curve. I'm still just bleeding my way through some parts because I don't know what everything means in Rust just enough to try different things.

I will say Rust is nowhere near where it could be, but it's at a stage where I think it's definitely usable. They definitely took their time to make sure they got things right, and they got plenty right.

[0]: https://crates.io/ [1]: http://langserver.org/

Post reply on HN