91–100 of 209 posts
simplicity source brain load Rust 95% Go 23%
more 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%Earlier quoted context omitted.
No. Standard libraries are a good thing, but if you want to write performant code, you definitely should consider a more specific implementation which is tuned to your actual problem. This is good practise in any programming language. But the rules of this benchmark page explicitly prohibit that, so languages, which don't have hash tables in their "standard" library have a strong advantage, which isn't a good represe…
In terms of performance, languages which don't have has tables in their standard library have an advantage in real life too, not just in the benchmark. While what you say is true, in great majority of the real life cases, if there's hash table implementation in the library, the developer will use that. If there's none, then they will start looking for one, making it more likely that they will choose a more fine-tuned…
A standard library for a language will most probably get more attention from developers than any external library.
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…
It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.
Even though Rust apparently "won" here(does anybody really win in such comparisons?) I don't care that much about it, because I don't consider this the main appeal of the language. It's the compiler error messages, memory safety and the lack of a Garbage Collector that speak to me more than raw performance.
Garbage collector is actually something you'd want, if it caused no performance hit.
For instance, if you never hit the GC memory limit in D, it's faster than manually managing memory since you never free it.
Earlier quoted context omitted.
It'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/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I don't find the code complexity obviously worse for the Rust version, y…
What 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?
Today, it is faster: 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).
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.
This is mainly do to firstly, Go just fits way way better for my shop. The transition from my fellow employees from Python to Go is pretty straight forward. Secondly, Go is just nicely setup for ease. I had so much hell in Rust cross compiling a simple https server.. it was mind numbing. It might be better now, but I was shocked at how difficult it was.
Finally, Go is just more nice to write in when you're.. well, writing it out. I guess I tend to write as I think about data structures, abstractions, general design. I don't draw it ahead of time or w/e, I just write code. Go is very minimal, and is pretty forgiving to quick rewrites/etc. In Rust I found myself writing myself into a corner constantly when all I was trying to do was get an idea out of my head.
With that said, I vastly preferred Rust's feeling of knowing exactly what my program is doing. No question on if something is nil or not, you know it is or isn't (or know it's unknown haha).
I think for me, in another 2 years I'll push again for Rust > Go in my shop as I imagine the Rust tooling will have improved to the point where it's easier and more quick to write things. Rust was experiencing a lot of cargo package churn, I spent hours debugging which packages worked together, it was a headache. Even understanding errors was a bit of a headache, despite the compiler trying really hard. Rust is making great strides though, and even though I use Go to get shit done, Rust is probably my favorite language.. that I don't use heh.
edit: Oh yea, and green threads, god do I wish Rust had green threads. I found Rust to be similar to Go in multithreading ergonomics, but I couldn't use them in the same manner as with Go - ie, fire off as many as I want. There are several libraries in development that should take care of this though, I believe.
Earlier quoted context omitted.
It'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/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I don't find the code complexity obviously worse for the Rust version, y…
Go 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/... 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?
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.)
Earlier quoted context omitted.
It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.
> Rust handles memory (de)allocation at compile time You are saying that Rust is doing its runtime memory allocation at compile time? Are you sure you don’t mean compile time management of memory? Two very different different things.
Not saying being explicit isn't important, just trying to understand you.
simplicity source brain load Rust 95% Go 23%
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.
Earlier quoted context omitted.
There are many predictable things in life: the tendency of up-and-comer languages to blitz these benchmarks due to careful optimization, and the tendency of people whose pet language has lost on a benchmark or two to get on here and write off the idea that anyone should ever benchmark cross-language. Some of the benchmarks are pretty ridiculous and flawed. Others look pretty straightforwardly comparable. I have troub…
I find microbenchmarks mostly useless. There are just too many variables in play. Also they tend to focus on the developer who optimizes code, not the journeyman developer in your company who actually writes code. C or Fortran looks fantastic on benchmarks, but if you forced all your developers to use C I doubt you'd see a similar outcome. They seem to push developers in the direction of coming up with simple rules o…
Performance optimizations tend to involve a lot of specialization, which means more code, which makes this ratio worse. The gzipped size is a proxy for the minimum description length/Kolmogorov complexity, which measures language expressiveness.