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.
You must log in or # to comment.
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
If that’s the measure then I’m more productive than all of Google combined. Nowhere in the definition says the project has to work as intended or even compile.
I know you are joking but needing to compile is probably one of the reasons “teams” are more productive in Rust.
You cannot check something into the build system unless you can build. Once Rust is compiling, you have eliminate scores of problems that may still be in equivalent C++ code.
Rust works to limit the damage one dev can do to the codebase.
I take that as a challenge. :)
But yes, that compiler checks and awesome linter is one of the main reasons I use Rust. I like working with concurrent and parallel code, and Rust makes that really safe.
“We’re abandoning projects at an unprecedented rate, proving our commitment to the bottom line.”
If you ask my last manager it’s “comments on issues”
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
Half the day coding, the other half the day bandaging their feet.
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).
it’s possible to design APIs in Rust that are literally impossible to express in any other language
This sort of violates what I’ve always heard about computer science. I’ve always heard logic is logic.
Hmm, yes and no. You can express a program that does anything in any language, but API design is as much about what can’t be expressed (with that API) as what can. A well designed API lets you do the things that are desirable while making it impossible to do things that aren’t. You can of course bypass APIs to do anything the language allows, even in Rust if you break out the unsafe blocks and functions there’s pretty much nothing you can’t bypass with enough effort, but you very much have to set out to not use the API to do that.
I think your quantifier of “any other language” is the issue. There are certainly languages with far more powerful type systems than Rust, such as Coq or Lean.
Maybe, although I’m not aware of any other language that has the same abstraction around ownership and lifetimes. Most other languages I’m aware of that have more (or equivalently) powerful type systems are also GCed languages that don’t let you directly control whether something gets stack or heap allocated. Nor due they allow you to guarantee that a variable is entirely consumed by some operation and no dangling references remain. While at a high level you can write something that accomplishes a similar result in other higher level languages, you can not express exactly the same thing due to not having direct access to the lower level memory management details.
See this example for Scala:
https://blog.tmorris.net/posts/scala-exercise-with-types-and-abstraction/index.html
Now go further and say you can’t compile a call that leaks memory, or things like that.
Disclaimer: I don’t know Rust so can’t verify the claim. All I can say is it sounds somewhat plausible.
It’s what C++ would look like if it had been designed today.
So, it’s C#?
/s
So, it’s C#?
No, that’s what Java would look like today if designed by a giant evil megacorp… or was that J++. Eh, same difference. /s
This did make me laugh though. Anyone else remember that brief period in the mid-90s when MS released Visual J++ aka Alpha C#? Of course then Sun sued them into the ground and they ended up abandoning that for a little while until they were ready to release the rebranded version in 2000.
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.
Good god I hope you’re more productive than the C++ people.
I don’t have to be productive, I know C++.
but not as productive as those using C
