7 ms·
simplicity source brain load Rust 95% Go 23%
by egnehots 8y ago
simplicity
source brain load
Rust 95%
Go 23%
- simias 8y agoIt's true that performance is not always the main metric to consider but in this case I'm not really sure that Go makes that much of a difference. Take the "regex-redux" benchmark for instance, compare the two versions: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-rust-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-go-2.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I don't find the code complexity obviously worse for the Rust version, yet it runs a full order of magnitude faster in this benchmark.
- weavie 8y agoGo seems to perform really poorly in the regex-redux. Against both Node and Python Go is way faster (as one would expect) apart from with the regex-redux.. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?
- tex0 8y agoThe benchmark is using some third party PCRE lib. This is probably necessary because Go's RE2 lacks some features, but it's not a good comparison.
- burntsushi 8y ago> This is probably necessary because Go's RE2 lacks some features No, it's because PCRE is faster than Go's standard library regex engine on this particular benchmark. There is another entry for Go (called just `Go` I believe) that uses Go's "regexp" package. The regexredux benchmark itself does not require any "fancy" features. It can be satisfied by pure regular expressions.
- deleted 8y ago[deleted]
- jerf 8y agoI disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. The exception is the regex benchmark, which has little to do with the languages and everything to do with the regex library used by the language. If the dynamic scripting languages were required to use regex engines implemented in pure Python/Perl/PHP/JS, their performance in the game would collapse on the regex benchmark. Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs. Benchmarks tend to hit cases where PRCE is faster, but it's not hard to construct a benchmark where the Go standard library will be arbitrarily faster than some of the other languages, because that's a characteristic of big-O differences. (In general, one should always be careful of claims that some block of code is X times faster or slower than another; the comparison only has meaning if they're in the same big-O class, or at least de facto in the same big-O class, e.g., O(n logn) and O(n logn logn) are basically the same class in practice. It's also important to make sure the problem being benchmarked is large enough to get past the constant factors that may be involved. I'm not saying those aren't important, but if you want an "X-times faster" sort of comparison you need to shrink the constant factors into irrelevance first. I've seen cases where people blithely claim some bit of code is 100,000 faster than some other, but really, it's a big-O difference.)
- weberc2 8y ago> I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. I think it can only tell you about the performance cieling, and even then it can't tell you that for languages like Go where fairly obvious optimizations (like arenas) are prohibited while all manner of clever tricks are permitted for other languages. Your remarks on performance comparisons were really insightful.
- igouy 8y ago>> obvious optimizations (like arenas) are prohibited No, not prohibited. Which widely-used third-party Go library do you suggest people use to implement Go binary-trees programs?
- chatmasta 8y agoWhat stuck out to me about the regex-redux benchmark is that PHP is faster than both of them! Is that because PHP is effectively a scripting language over C, especially for well-defined tasks like regex matching?
- burntsushi 8y agoI don't know personally. In Oct 2017, the PHP version was slower: http://web.archive.org/web/20171027211857/http://benchmarksgame.alioth.debian.org/u64q/regexredux.html http://web.archive.org/web/20171027211857/http://benchmarksg... Today, it is faster: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... As far as I can tell, the source code of the benchmark didn't change at all. The only difference between them is that former uses PHP 7.1 and the latter uses PHP 7.2. So... I would start at the differences between PHP 7.1 and PHP 7.2. I would also first attempt to reproduce the result locally, to rule out changes in environment in the benchmark game (speculatively speaking).
- weavie 8y agoYou aren't really going to experience Rusts complexity when your program is essentially just a single function, so it probably isn't really a fair comparison..
- v_lisivka 8y agoWhen programs grows in complexity, Rust shines. Extra guarantees are very handy when code refactored. It hard to compile Rust code, but when it compiled, it usually works (or quickly points out to problem). I actually use it in parallel with C/C++ legacy code, and I just trying to avoid C/C++ as much as I can, because I newer saw segfault in safe Rust code so far.
- smcl 8y agoEspecially when you're just reading some pre-written code. I've rarely (never?) seen any complaints about how reading Rust is hard ... but lots which say that writing the code itself can be frustrating
- Dowwie 8y agoThere's a "matrix moment" where a programmer familiar with Rust no longer sees cascading green characters but rather the program itself.
- codedokode 8y agoAlso, in readability Go wins. Because you don't have to put single quotes and HTML tags after every variable.
- ghr452 8y agoI think syntax ends up being mostly superficial. The real readability gains come from being able to map().filter().sum() instead of needing 3 for-loops mutating outer variables.
- divan 8y agoWhich part of a for loop is unreadable?
- Volt 8y agoRight, you use aboriginal angle brackets instead.
- larschdk 8y agoFor toy programs you are correct, but Rust guarantees way more than Go in terms of correctness. If you need to reason about, implement and debug such correctness, I don't think the difference is a factor 4. In fact, Rust's proposition is that it makes it easier to ensure (less easy to forget about) correctness.
- flavio81 8y agomore benchmarks source generics Rust 100% Go 0% source if err!=nil return { nil, err }; Rust 0% Go 100% source undeserved hype Rust 100% Go 100%
- jimmy1 8y agosource: good generics implementations Haskell: 100% All Other Languages: 0% source: flawed generics implementations Haskell: 0% All Other Languages: 100%
- IReplyToRetards 8y agosource: good generics implementations Coq: 142% Haskell: 91% All Other Languages: 0%
- notheguyouthink 8y agoSidenote, appending to that list, my NodeJS "brain load" was insane. When I switched from Node -> Go ages ago it was night and day. Funnily, in some scenarios, I find Rust to be less of a brain load than Go. In others, Rust is way way worse. As I mentioned in another post, we use Go to get shit done. I hope Rust can take that mantel some day.
- deleted 8y ago[deleted]
- pjmlp 8y agoI try to get shit done, but end up spending my time writing code templates for //go:generate.