I struggled for years with a chronic misunderstanding of Go. I kept trying to compare it to the usual suspects in the "next systems language" crowd (D, Rust, Zig). That wasn't quite right.<p>Once I realized that its sweet spot is large-ish services that you want closer to the metal than Java but for which would be silly to go as low level as C++, Go fans started making a whole lot more sense to me.<p>I'm still not a Go fan personally—my taste in programming languages slants toward the more expressive end of the scale (C#, Rust, Scala). But at least I'm no longer confused by trying to make Go make sense where it doesn't.<p>It's a very good tool for its kinds of jobs. Other languages also have their points of unreasonable effectiveness, too.
When I first read that, I thought the core conclusions were still mostly correct, but the delta claimed for Rust over Go was too large. Rust will certainly beat Go on this metric (I expect Rust to even beat C and C++ at scale [1]), but by a factor of 3 is probably on the large side.<p>There are other things that I would consider questionable as well; Haskell might be capable of beating Go if you really, <i>really</i> work at it, but what you might call "casually written Haskell" isn't going to perform anywhere near as well as casually written Go. And the degree of knowledge required to write high-performance Haskell is much higher than high-performance Go. You have to have more than just knowledge of Haskell as a language, you have to have a fairly deep understanding of exactly how GHC compiles and optimizes it. This can be scaled to the Shootout, but scaling it to real code is very difficult.<p>Still, I think the general point is well-taken. I'm less worried about the environmental impact of my code because my code runs at scales where even if my code was running for "free" from an environmental impact, it wouldn't save much of anything. But having used Go for a while, I'd have a really difficult time moving back to a language that is literally dozens of times slower, and, yes, consumes dozens of times more energy as a result. Part of the reason <i>why</i> my code runs at such small scales is that it's reasonably efficient code. I have a couple of services that I consider trivial, but if I were writing them in Python, would be non-trivial. Still not exactly monsters that would be eating clusters of machines at a time, but there's still a lot of practical operational difference between "This occasionally spikes to 25% of a CPU for a minute at high loads" and "This occasionally spikes to consuming 10 full CPUs for a minute at high load", and that's a fairly reasonable multiplier. I have several services that would have deltas like that.<p>[1]: A previous comment of mine: <a href="https://news.ycombinator.com/item?id=25625362" rel="nofollow">https://news.ycombinator.com/item?id=25625362</a>
Benchmark sites really need categories like speedruns. The finish line is something like "takes a dynamic input and gets the right answer". Then you have categories that do it under some additional constraints:<p>any% (most languages call out to pre-written machine code, probably)<p>language% (anything possible using just that language)<p>idiomatic%, casual%, singlethreaded%, memory%, compile-run%?, safe%? etc.<p>Then at least we'd be able to argue about which categories a particular benchmark result would apply to, and <i>separately</i> argue about which categories matter in a particular domain.
I agree with rsc about that study having problems, [1] but I'm not sure this part is accurate:<p>> Second, the summary of the Discord post about switching from Go to Rust is incredibly misleading. The original Discord post showed a single graph plotting both a Go server and the equivalent Rust server. The Rust line had more predictable performance and avoided the latency spikes in the Go line, but the lines were roughly comparable. Instead, the AWS post displayed the Go graph next to a graph of the Rust server after a significant rewrite to use new data structures and more RAM, circling “ms” vs “µs” time scales. This is either a complete misunderstanding of the Discord post or blatant dishonesty.<p>The discord post [2] says this:<p>> After the service ran successfully for a few days, we decided it was time to re-raise the LRU cache capacity. In the Go version, as mentioned above, raising the cap of the LRU cache resulted in longer garbage collections. We no longer had to deal with garbage collection, so we figured we could raise the cap of the cache and get even better performance. We increased the memory capacity for the boxes, optimized the data structure to use even less memory (for fun), and increased the cache capacity to 8 million Read States.<p>He paraphrased "optimized the data structures to use even less memory (for fun)" as "a significant rewrite to use new data structures". The post doesn't say how involved the optimization was, but I got the impression it might have been pretty trivial to shave a few bytes off the most common allocation or some such.<p>And as for increasing the cache capacity, that's something Rust allowed them to do without problems but Go 1.10 didn't, so I think it's entirely fair to include it in the comparison. Maybe Go 1.18 would also have been able to do this, but unless Discord dusts off their old server to aid people choosing a language in 2022, we're not going to really know...<p>[1] and even made a similar argument here: <a href="https://news.ycombinator.com/item?id=30313943" rel="nofollow">https://news.ycombinator.com/item?id=30313943</a><p>[2] <a href="https://discord.com/blog/why-discord-is-switching-from-go-to-rust" rel="nofollow">https://discord.com/blog/why-discord-is-switching-from-go-to...</a>
> <i>Most obviously, if your study claims that C++ uses 34% more energy, 56% more time, and 14% more memory than C, it’s time to reexamine your assumptions. Approximately every C program is a valid C++ program, so C++ can’t lose, especially not that badly!</i><p>Benchmarking software is so easy to do wrong. It's so easy to manipulate the results if you are so inclined, and even when you're trying to be evenhanded it's so easy to disadvantage one of the systems under test.<p>Different approaches are called for with different tools, and the classic error we see over and over again in benchmarking studies is the inappropriate application of idioms which suit one of the competitors across the others.
Russ argues that since you can compile lots of valid C programs as C++, surely C++ "can't lose" but this is a revealing error.<p>It's true that lots of valid C programs are also valid C++ programs <i>but</i> it is not true that those programs will mean the same thing when treated as C++, nor does it mean that all C++ compilers are automatically just as good at optimising all possible valid programs as C compilers, and so the <i>code</i> which you get out and then measure may be quite different.
The versioning scheme used in Go may be somewhat misleading to outsiders. There are often significant runtime changes between versions, but only the minor version is bumped. For example, adding generics to C# (among other things) prompted the C# team to bump the version of the language from 1 to 2. Go adds generics in 1.18, and if you don't follow the news, you won't know it's not just a minor improvement over 1.17, but one can say a whole paradigm shift (we've been waiting for generics for 13 years). So perhaps many people think there's nothing wrong about using old benchmarks for Go 1.10 because it doesn't feel like a lot must have changed between 1.10 and 1.18
I'm really glad to have Rust and Go. I was worried the only way out of startups using scripting languages was Java or C++.<p>Thanks to everyone that has contributed to these great languages! It's so nice to be able to simple things that are such an after-thought in other languages.
Alternative way to read the Twitter thread: <a href="https://nitter.net/_rsc/status/1496352325157457922" rel="nofollow">https://nitter.net/_rsc/status/1496352325157457922</a>
To what extent are the resulting co2 emissions of a program linked to its runtime resource use? On a succesful SV "web scale" app they are no doubt notable, but for 99.999% of programs the costs of getting it written surely dominate. The CO2 footprint then comes from the resulting consumer spending and other downstream economic activity, quantifiable by carbon intensity of the economy ($/kg/CO2e). [1]<p>As a thought exercise, think what happens when a company engages a consultancy to make a Postgres backed Java or Python app running in AWS to replace a business process run previously in a overgrown Excel sheet and brain of a soon to be retired domain expert.
Programmers are hired, (second) cars are bought, overseas vacations are had, what happens to co2 emissions? The choice between Java or Rust makes zero difference. The choice between Java and Excel might, but not because of runtime performance...<p>TLDR; almost always it's the development budget, not CPU use.<p>[1] You can see this number by country at <a href="https://ourworldindata.org/grapher/co2-intensity" rel="nofollow">https://ourworldindata.org/grapher/co2-intensity</a> - about 0.1 - 0.6 kg/$ in industrualized places
I don't know. This reads more like a case of sour grapes. The discord article clearly states that some of the optimisations (like data structure improvements and especially the larger cache bucket sizes) weren't possible at all due to the way Go's garbage collection works (scanning for the entire structure rather than few changed bits). May be that improved with the latest Go version? Even if it did, it's not possible to have the same predictable performance from any GC languages for that particular use case which seem to be suited for a non GC language.<p>Fair points about c++ and the overall deficits in the original study that doesn't use comparable programs across languages.
Really comes down to "Do you want GC spikes or not?" and the tail latencies that go with it (clearly visible in the images in the tweet thread). The alternative, before Rust, was to use C or C++, and I'd never consider writing a Java or Go service in C++. Rust doesn't just bring safety to C, it brings an ecosystem that brings a "system language" up to the point where I'd consider it for general services.<p>Edit: deleted java vs go comment, and replaced with the evidence at hand
A link back to the post so folks who haven't read it thoroughly can follow along: <a href="https://aws.amazon.com/blogs/opensource/sustainability-with-rust/" rel="nofollow">https://aws.amazon.com/blogs/opensource/sustainability-with-...</a>
Has anyone done a separate study to corroborate, contradict, or otherwise update the work of this 2017 paper?<p><a href="https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf" rel="nofollow">https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...</a><p>Also, a suggestion for anyone who plans to do an update: please put a <i>version number</i> on the languages you use, and also note which specific versions of compilers, VMs, GCs, etc. were used.
> Approximately every C program is a valid C++ program, so C++ can’t lose, especially not that badly!<p>He doesn’t seem to be aware that The Benchmarks Game has a moderator who requires the contest entries to be “idiomatic” for each language (details of what counts as idiomatic are of course contentious), so a C program that doesn’t use C++ features/idioms would not be accepted in the game.
I really don't see how it's misleading. It shows their rust implementation after some tuning vs their go implementation, which I'm sure was tuned as well.
This doesn't surprise me. Rust's toxic community was one of several reasons that made me turn away from the language. When people ask on a Go forum (e.g. r/golang) whether they should switch to or write a project in Go, they tend to get good and professional advice, and often this advice is to stick with the existing language and approach. I don't know why this is so, but with Rust you mostly get zealots with zero ability to evaluate the Pros and Cons of their language of choice.
The Golang fanboyism is getting out of hand. Rust may not be the flawless language zealots tend to believe but at least it has something new to offer that was missing from the PL ecosystem and many other features that the industry didn't take seriously till lately cause they were "only for research languages".<p>I don't even get why Golang is considered a good language. The new goto primitive for concurrency, the half baked error handling, the fact that it's designers think that programmers are not smart enough and made a language that looks like Java and feels like Python (but hey, no class inheritance and the compile times are faaast) are just a few of the examples that don't make it good enough for me. I wonder how popular Golang would have been if it wasn't backed up by it's company.<p>What is this tendency for the software industry to try and make everything "easy"? Trying to oversimplify something that is inherently complex only adds accidental complexity.