Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

Full quote: "Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++."

From his keynote presentation the RustNation UK conference.

It's easy to be 2x productive in a language that's bound to be biased toward greenfield projects.

They actually were given the same projects! It was anonymously self-reported.

I do not wonder about the double productivity increase compared between Rust and C++. But what really makes me wonder is the comparable productivity of Rust vs. Go. I thought Go is much easier than Rust and that people could write applications much faster in Rust. I would expect that Rust takes at least 2-3 times more time to write an application, compared to Go, but then I would also expect it to run at least 2-3 times faster than the Go version, hence it is a fair trade-off.

I don’t mean this post to be about Go; I have never written significant amounts of Go and have no opinion on its productivity.

Productivity in Rust is difficult to talk about, because of differences in opinion and what I like to call “the TCO problem.”

Because Rust is hard to learn, a lot of folks assume it’s that hard all the time. Which means they assume things take just as long for a new Rustacean as they do an experienced one. This is generally not the case. Once things click and you’re over that hump, it feels like programming in any other language. If there are similar libraries available and I don’t need to create the world from scratch, I am just as productive in Rust as in other languages that also have those libraries, generally.

But that kinda leads into the other thing I alluded to; a lot of people think of “productivity” as “whatever lets me see something quickly.” But this doesn’t capture real prodctivity, in my mind, which includes the total development time, aka, how many bugs do I have to deal with later. Rust moves a lot (but not all, of course!) of this up front. Which can feel like it slows you down (but again, with experience, I find this is actually kinda minimal), but then you save time on the back end by needing to debug less. This means that robust features end up being developed more quickly than in some other “productive” languages I’ve used in the past.

TL;DR things aren’t simple, and “fast to get going” doesn’t inherently mean “productive.”