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.
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.
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'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..."
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 π."
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.