Enough with the Zero Sum Game of Rust vs. Go – InApps Technology 2022

Last week, in our weekly roundup of programming-related news bits from around the web, we briefly pointed to an article published by Amazon Web Services (AWS) that touted the sustainability of the Rust programming language. Written by Shane Miller, the chairwoman of the Rust Foundation, and Carl Lerche, a principal engineer with AWS and creator of the Tokio asynchronous Rust runtime, the article argued that Rust beat out many other languages in terms of efficiency, with AWS saying that it was “investing in the sustainability of Rust, a language we believe should be used to build sustainable and secure solutions.”

While the article was certainly not the first to suggest that Rust could help with environmental concerns by offering a more efficient programming language, it was the references to Go, a language often posited as a competitor to Rust, that brought about a bit of disagreement this week, in the form of a Twitter thread by Go principal engineer Russ Cox.

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/

— Russ Cox (@_rsc) February 23, 2022

In the thread, Cox argues that two primary data sources for the article, a study from a few years ago and a blog post from early 2020 regarding Discord’s decision to switch from Go to Rust, offer inaccurate perspectives regarding Rust’s supposed superiority to Go for performance and efficiency.

The study, writes Cox, “has obvious problems,” because not only is it five years old, but it refers to an old version of Go running on now-out-of-date hardware. Also, Cox points out that the study uses the Computer Language Benchmarks Game as “a source of comparable programs, which is not remotely true if you know that site.”

“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,” writes Cox.

Literally all of the Rust people I talk to (myself included) strongly dislike that study and that site being brought up in this sort of discussion, despite it painting Rust in a positive light. It’s so so unrepresentative if not outright misleading.

— Chris McDonald (@deepinthebuild) February 23, 2022

On the second point, the Discord blog post, Cox again points out that the data points involved refer to a now old version of Go, which makes a difference for this argument, as well as what he calls an “incredibly misleading” summary. While he says that the Discord blog post itself offers “an apples-to-apples comparison of a Go server and the equivalent Rust server,” he argues that the AWS post was, instead, a misrepresentation.

The real crux of Cox’s arguments arrives in his final two tweets, which serve as a bit of a call for peace.

“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,” writes Cox. “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.”

Cox finishes with a link to an article published on InApps Technology which argues that Rust and Go are better together, rather than as competitors. Co-written by members of both the Rust and Go teams, the blog post argues that “While others may see Rust and Go as competitive programming languages, neither the Rust nor the Go teams do. Quite the contrary, our teams have deep respect for what the others are doing, and see the languages as complimentary with a shared vision of modernizing the state of software development industry-wide.”

Agreed: pic.twitter.com/Qes0iHcV13

— Rémy Rakić (@lqd) February 23, 2022

This Week in Programming

• GitHub Opens Up Vulnerability Advisory Database: While the idea of open source security has become increasingly popular in recent years, the ability to contribute one’s knowledge to vulnerabilities is something that has remained limited. However, GitHub has now opened up its Advisory Database to community contributions. The Advisory Database, a database of CVEs and GitHub-originated security advisories affecting open source software, has been published to a new public repository, alongside a user interface for making contributions. The database is licensed under a Creative Commons license and is maintained by a “dedicated team of full-time curators” who will review suggested improvements to existing CVEs. GitHub is using the Open Source Vulnerabilities (OSV) format for the database “in the spirit of furthering interoperability,” and the database will serve as the basis for vulnerabilities in npm, NuGet, and GitHub’s own Dependabot alerts. To contribute, users can navigate to the advisory they want to add information to and follow the “suggest improvements for this vulnerability” workflow, or submit a pull request directly.
• Prebuilt Codespaces for Large Repos Goes Beta: For organizations with large repositories, starting up GitHub’s Codespaces can be a time-consuming activity. In response, the company has been running a private preview of the ability to prebuild these codespaces. While they say that feedback has been largely positive, they also received “a ton of valuable feedback around the configuration and management of prebuilds.” This week, the company has extended the private preview into a public beta, alongside some changes made in response to that feedback. Prebuilding the codespace speeds up the startup time for large and complex repositories, giving companies “a ‘ready-to-go’ template where your source code, editor extensions, project dependencies, commands, and configurations have already been downloaded, installed, and applied so that you don’t have to wait for these tasks to finish each time you create a new codespace.” In addition to entering into a public beta, GitHub has also added several updates, such as support for GitHub Actions workflows that will be managed by the Codespaces service, and prebuild configurations that are built on GitHub Actions virtual machines. Prebuilds are available for all organizations with GitHub Enterprise Cloud and Team plans, and the prebuilds documentation will help you get started.

An incomplete list of phrases to avoid with developers

– It’s simple to use
– It does exactly what you need
– It’s highly scalable

— Adam DuVander (@adamd) February 24, 2022

• Porting Linux eBPF to Windows? It’s been almost a year now since Microsoft said it would be bringing eBPF to Windows. Recently, they offered an update on their progress, and now they say they want to “meet developers where they are” and so they have offered a guide to getting Linux-based eBPF programs to run with eBPF for Windows. Since we have been keeping a close eye on eBPF for a while now, we thought this would be worthwhile to point out. In the post, Microsoft offers their “learning and observations using an application that was fundamentally written for Linux” — the Cilium Layer-4 Load Balancer — as a “very relevant real-world use case.” Beyond that, they also offer some insight into what’s next for eBPF on Windows, writing that they “will continue to be application-centric with a focus on hooks and helpers” and that “maximizing eBPF source code compatibility will continue to be an important goal,” with the topic of how to accept signed eBPF programs currently in active discussion.
• Rust Opens up about Compiler Ambitions, Rust-Analyzer Addition: The Rust Compiler Team has some ambitions for 2022 that they’ve decided to share with the community at large, including overall themes for the year, the concrete initiatives they have resources to drive, and greater aspirations they would tackle if they had more help (hint hint). So, for you Rustaceans out there, give the blog post a read and see if there’s something you can help out with. As they note, “Rust is not a company” and “the goals that we set for the project must be aligned with the goals of our current and future contributors; otherwise, they just won’t get done.” Outside of that, the Rust team also announced that rust-analyzer has joined the Rust organization. The rust-analyzer project is a new implementation of the Language Server Protocol (LSP) for Rust, and its joining of the Rust organization “unblocks technical work to make rust-analyzer the officially recommended language server for Rust in the near future.” Rust-analyzer is currently available for VS Code, NeoVim, Vim, Emacs and more.

Context: JetBrains’ founders are Russian. They have offices in Moscow and Saint Petersburg. Free speech isn’t really a thing in Russia. To openly condemn the actions of the Russian government could have serious repercussions for them, but they did it anyway.

Спаси́бо, JetBrains. https://t.co/oAsmCDkx3U

— Dylan Beattie (@dylanbeattie) February 24, 2022