Thread by @_rsc

I wasn’t going to say anything, but since ZDNet has republished the AWS “Sustainability with Rust” blog post, a short thread about why that post is misleading (at best) about Go. 1/

First, the “really interesting study a few years ago” has obvious problems. To start, it was published in October 2017, using Go 1.6 (Feb 2016), on an Intel i5-4460 CPU (Q2 2014). That’s forever ago. 2/

On top of that, the “really interesting study” assumes the Computer Language Benchmarks Game is a source of comparable programs, which is not remotely true if you know that site. 3/

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! 4/

All this is to say that the “really interesting study” is not really interesting. In fact it should clearly be viewed with a healthy amount of skepticism. 5/

Second, the summary of the Discord post about switching from Go to Rust is incredibly misleading. 6/

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

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

As an aside, I’ve used that kind of scale change to make a point myself before (swtch.com/~rsc/regexp/re…). It’s a good way to make the point when you are showing an honest, fair comparison. But the AWS post wasn’t that. 9/

To be clear, the Discord post was fair. It showed an apples-to-apples comparison of a Go server and the equivalent Rust server. Much later in the post, it graphed the Rust server again, alone, with rewritten data structures and extra RAM. The AWS post misrepresents that. 10/

That said, the Discord post also describes Go 1.10, while Go 1.18 is due out soon. There have been many improvements in those eight releases, reducing GC pauses in programs with very large heaps or very many goroutines (and the Discord server had both). 11/

So the Discord latency spikes would be significantly reduced using a recent Go, and we also have plans to reduce them further. But still, Rust is a fine language for that server, and the team made a reasonable call. (Waiting for Go to improve could have worked too.) 12/

The AWS post does make some honest, fair points about Rust, which makes it even more of a shame that they included these misleading statements about Go. They didn’t need to do that. Rust is good enough to stand on its own. 13/

Personally, instead of reading blog posts that pretend Go vs Rust is some kind of zero sum game, I would much rather focus on ways that Go and Rust complement each other and can work well together. Like this post:

thenewstack.io/rust-vs-go-why…

14/14