Productivity of Rust teams at Google

Productivity is so vague though, Id be interested to see what exactly they measured

I was a lot more productive in C++ 15 years ago when the current project was 100% greenfield. Now that the code is 15 years old I'm much less productive because over the years we have discovered mistakes we made. I suspect I'm still more productive than the average C++ programmer because 15 years ago modern C++ was known (c++11 was still a couple years away though) and so we didn't do a lot of the mess that people hate on C++ for.

Which is to say I want to know how productive those programmers will be in 15 years when the shiny of rust has warn off and they are looking at years of what seemed like a good design but current requirements just don't fit.

I'd love to know how they measured this, because if they just took two Jira boards for two projects, compared the ticket times, and said "yep, Rust is good" that's both insane and completely expected by some big tech managers.

I don't deny it, it's just nice to see reasoning with a headline, so that I could take it to another team and say "let's try Rust because..."

Is it because c++ devs need half their day for recovering from the trauma of reading and writing c++? /s

I don't know. After writing rust for a while, and slowly putting programs together, I tried Go and I feel so relived I can just write what I want in 10 seconds instead of messing with lifetimes, borrow checker and other stuff I actually don't care about at all.

A more experienced colleague said that yes that is true, but Go can't guarantee your code is correct, so you will spend time fixing your code also in Go. Probably true.

Commenter on Reddit (OP there) gives a talk link and summarization:

In the talk, Lars mentions that they often rely on self-reported anonymous data. But in this case, Google is large enough that teams have developed similar systems and/or literally re-written things, and so this claim comes from analyzing projects before and after these re-writes, so you’re comparing like teams and like projects. Timestamped: https://youtu.be/6mZRWFQRvmw?t=27012

Some additional context on these two specific claims:

Google found that porting Go to Rust "it takes about the same sized team about the same time to build it, so that's no loss of productivity" and "we do see some benefits from it, we see reduced memory usage [...] and we also see a decreased defect rate over time"

On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain."

They should compare defect rate with the Go teams. I'm curious if the advertised benefits of Rust's type system give some practical advantage.

EDIT: Just watched the actual talk. Apparently they did this comparison, and found that Rust has fewer defects when compared to Go.

That’s pretty cool. I’m not advanced enough to really understand all the ways rust is better but I read nothing but good things about it. It seems pretty universally loved.

I feel like they are just trying to Subliminally push Go and failing at the Subliminal part.

Good god I hope you’re more productive than the C++ people.

I don't have to be productive, I know C++.

Is the armorer going to get someone shot by being really sloppy with safety checks?

That’s the real question.

but not as productive as those using C