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 register to comment.
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.
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.
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 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.
