Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Credits
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
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."
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.
Early in the development of D they had two competing standard libraries that each provided nearly identical functionality but were incompatible with each other. Neither one was obviously the correct choice, and so their library ecosystem split in two, with some projects choosing to use one, while others picked the other one. Of course once a library decided to use one standard they were then locked into it and could only use the other libraries that had made the same choice.
I believe they eventually came to a solution where they merged the two libraries into a new one and deprecated the old ones, but for a while there it was an absolute mess in their ecosystem.
Can confirm, I was super excited about D about 10-15 years ago when all of that had recently been resolved. It's a really cool language, but it didn't really get much traction and Rust solves a lot of the problems I have with it, so I use that now.
That said, here are some features I really miss from D:
But at the end of the day, Rust provides more guarantees, enough features, and a fantastic ecosystem. But if both had the same ecosystem today, I would give D a serious consideration.
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 π."
At the end of the day, the first thing managers do is convert story points / tshirt sizes / whatever other metaphor back into time estimates. So why bother with the layer of indirection.
I'll die on the hill that most teams do not need scrum / agile and all the ceremony that always goes with it.
A kanban board with a groomed Todo column is all you need. Simple and effective and can easily adapt to unexpected scope changes a.k.a production incidents.
*yes I'm aware that if you're getting bogged down in ceremony you're doing Agile wrong. I've never seen or worked in a place where I've felt it's been done right
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.
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:
The advantages of static types is not just finding bugs (though it does do that quite well). It also massively helps with productivity because a) types are now documented, b) you can use code intelligence tools like renaming variables, go-to-definition, find-references, etc. (assuming you use a good editor/IDE).
In general stronger types are better but I do think there is a point at which the effort of getting the types right is too high to be worth the benefit. I would say Rust hasn't reached that point, but if you look at formal verification languages like Dafny, it's pretty clear that you wouldn't want to use that except in extreme circumstances. Similarly I think the ability to use an 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.
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.
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.
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.
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.
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
It is much, much more difficult to make Go run as fast as Rust compared to writing that faster in the first place Rust program.
It’s a fair point that the speed of a language is not everything, but that’s not my point. My point is that with C++, the programmer must often play a puzzle of avoiding common pitfalls with e.g. memory allocation - on top of the actual problem the programmer is intending to solve. This hurts productivity, because there’s so much more to be mindful about.
Both Rust and Go are more free from this kind of extra mental overhead. The programmer can focus more attention on the actual problem. This is probably why Google has observed that both Rust and Go developers are twice as productive than C++ developers.
Go makes the trade off of using garbage collectors, which is easier for programmers to work with but comes with extra performance cost.
Having a simple and verbose language is not necessarily a downside. I’d rather take a simple language over all the syntactic sugar that comes with Perl.
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.
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.