Productivity of Rust teams at Google
Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”
In small print it says the data is collected over 2022 and 2023.
Productivity is so vague though, Id be interested to see what exactly they measured
Its google, so probably the number of projects launched, never advertised, then abandoned
It seems likely biased as well unfortunately if they let teams decide on their own what to use. I would wager that teams who on their own switched to Rust are probably teams that were already productive.
If you ask my last manager it’s “comments on issues”
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 suspect a large part of that will depend on how well Rust keeps the feature creep in check. C++ was a bit of a language design magpie. Pretty much any language design idea anyone had ever got pulled into the language and it turned into a real mess. Many of those features are incompatible with each other as well, so once you use one feature, you're no longer able to use one of the competing ones, which has lead to partial fragmentation of the ecosystem (interestingly enough D who set out to be a "better" C++, also ran into a similar but far worse situation). Many of those features have also been found to be problematic in various ways and have fallen out of favor recently and so are viewed as warts on the language, or failed experiments.
Rust is still young, so there aren't very many competing features, and none that I'm aware of that are considered things to avoid. If it can manage to keep it's feature set under control by actively deprecating and removing features that are problematic, and being more judicious than C++ was in pulling in new ones it should be able to avoid the same fate as C++. Time will tell I suppose.
I feel like I work well even without the new C++ features smart pointer stuff, simply because:
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..."
Eww... you're probably right. TIHI.
On a related note, I've always preferred t-shirt sizing over story points. You can still screw that up by creating a conversion chart to translate t-shirt sized into hours (or worse, man-hours) or story points, but at least it's slightly more effort to get wrong than the tantalizingly linear numeric looking story points.
If I was truly evil I'd come up with a productivity unit that used nothing but irrational constants.
"Hey Bob, how much work do you think that feature is?"
"Don't know man, I think maybe e, but there's a lot there so it might end up being π."
Yeah, it's different projects, most probably on different levels.
And considering recent layoffs, having different calibre of programmers on each.
Is it because c++ devs need half their day for recovering from the trauma of reading and writing c++? /s
Half the day coding, the other half the day bandaging their feet.
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.
Right, it's essentially the same argument as strong vs. weak typing. The weak typing proponents say JavaScript is best, because you can just write anything and you don't need to worry about all those pesky types getting in your way. The strong typing proponents (which if it's not obvious I am one of) point out that you can write incorrect code quickly in just about any language, but writing correct code is much harder, and the cost of correcting code increases the later the mistake is found. Errors that can't even be written are better than errors that are found at compile time which are better than errors that are reliably caught at runtime, which are all infinitely better than errors that only randomly appear under very specific circumstances.
That is why many people switched to using TypeScript for their websites instead of JavaScript, because even though you have to spend more time putting type annotations on everything, and at the end of the day at runtime TypeScript is literally just JavaScript, the errors it lets you find at compile time instead of runtime make the effort necessary to include those types worth it. Same thing applies with Rust vs. Go. Yes it requires more thinking up front when you're writing Rust code, and yes it might take you longer to write that code, but it's also going to be correct code you can be confident in and not have a bunch of ticking timebombs waiting in it that you don't even know about.
An extra 30 minutes spent having to think about a dozen lines of code, is infinitely preferable to spending 3 hours pouring over stack traces and single stepping debuggers to find that one subtle mistake you made.
I totally agree, though I think it's worth adding:
any or dynamic escape hatch is quite useful, even if it should be used very sparingly. Preach 🙏
instead of messing with lifetimes, borrow checker and other stuff I actually don’t care about at all
There's nothing wrong with putting Rc<> or Rc<RefCell<>> around data if you don't want to fight the borrow checker or think about lifetimes even if you know it can be written without.
Or even just clone. Depending on use case the performance cost would be negligible.
Really? I might have agreed for some other languages, but Go is so bare bones it feels like it takes way longer to write simple stuff than with Rust - you have to tediously write out loops all the time for example.
Tbf I haven't used it since it got generics. Maybe it is better now.
#Rust is not high level at all, change my mind.
Rust gives you high level abstractions but also allows lower level control over the hardware. These are not mutually exclusive.
You can easily argue almost any language is high level though, it is such a nebulous term that it is almost meaningless.
But Go has garbage collection so that code is as correct as that of Rust. Go is just a little less performant
Rusts ownership model is not just an alternative to garbage collection, it provides much more than that. It's as much about preventing race conditions as it is in making sure that memory (and other resources) get freed up in a timely fashion. Just because Go has GC doesn't mean it provides the same safety guarantees as Rust does. Go's type system is also weaker than Rusts even setting aside the matter of memory management.
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."
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.
Basically modern language with modern tooling. It's what C++ would look like if it had been designed today. The big thing though is the abstraction of ownership and lifetimes which took C++ ideas of scopes, smart pointers, and destructors and polished them into something much more powerful. Simply put it's possible to design APIs in Rust that are literally impossible to express in any other language, and that's a big deal.
Added on top of that is a modern dependency management system that is severely needed in languages like C and C++, and a very powerful meta programming system that enables compile time code generation and feature selection that's much safer and powerful than C and C++ fairly primitive pre-processor (although C++ STL does come close).
Added on top of that is a modern dependency management system that is severely needed in languages like C and C++
I won't disagree, but what Rust did is not the correct answer. Better than C++ perhaps, but not good enough. In the real world my code is more than Rust. I'm having trouble using rust because all my existing code is C++ and the dependency management does not work well with my existing build system and dependency management. If you want a dependency manager it needs to cover all languages and be easy to plug in whatever I'm doing currently. This is NOT an easy problem (it might not even be possible to solve!), but if you fail you are useless for all the times where dependency management is hard.
Compared to C++, Rust does a lot of things for you to prevent common mistakes. This reduces a lot of the mental overhead that comes with writing C++ programs. Go does this as well, but at the expense of slower programs. Rust programs are still as fast as C++ programs.
I think focusing on speed of programs is looking at the wrong thing. It's true that at the moment Rust programs are usually faster than equivalent Go programs, but it's already possible to very carefully tune a Go program to achieve similar levels of speed. The real difference is in productivity.
Go makes the tradeoff that it's much more verbose, it takes many times the lines of code to achieve in Go what's possible in either Rust or C++. This is because of their dogmatic obsession with keeping the language "simple". Yes that makes it easy to learn, but it means if you have something complex to express you need to use more of those simple building blocks to do so rather than just a handful of the more complicated ones you're provided in Rust or C++. More lines of code is more opportunity for mistakes to be made and more code to maintain. In a more powerful language you can offload much of the work to libraries that are maintained by other people and that expose powerful APIs that are safe to use. In Go because it's "simple" it's hard to write powerful APIs that aren't filled with footguns and are more complicated to use.
The problem with C++ wasn't that it was a complicated language, it's that it was an inconsistent language. There were many competing ways of accomplishing things and many of them were mutually exclusive with each other and introduced footguns. It was far far too easy to write code in C++ that looked correct but was utterly broken in very subtle and hard to detect ways. The Go guys looked at that situation and decided the problem was that the language was too complex and had too many features (arguably true), but decided to make the exact opposite mistake by designing a language that was too simple and had too few features.
A lot of it is about moving problems from runtime to compile time. JS, for example, has most problems live in runtime.
Imagine you're hiring an event planner for your wedding. It's an important day, and you want it to go well and focus on the things that matter to you. Would you rather hire an even planner that barely interacts with you up until the wedding because they're so "easy to work with"? Or one that gets a ton of info and meets with you to make sure they can get everything they need as early as possible?
Rust is like the latter. JS is like an even planner who is just lazy and says "we'll cross that bridge when we come to it" all the time.
C++ is like a meth addict.
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.
I feel like they are just trying to Subliminally push Go and failing at the Subliminal part.
Google: It's a three-pronged attack: sub-liminal, liminal and super-liminal.
Lisa: Superliminal?
Google: I'll show you. (leans out of window) Hey, you! Code in Golang!
Carl: Uh, yeah, all right. Lenny: I'm in.
Good god I hope you’re more productive than the C++ people.
I don't have to be productive, I know C++.
What do you mean by that?
Is the armorer going to get someone shot by being really sloppy with safety checks?
That’s the real question.