Probably hobbyists were more likely to join rust side after learning about its pros?
Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
11–20 of 41 posts
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#12How was productivity measured? I doubt that teams of Rust and C++ developers were given the same projects to implement.
They must have a ton of comparative data on releasing new chat apps.
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#13For everyone asking: 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."
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#14Probably hobbyists were more likely to join rust side after learning about its pros?
People working at Google are by definition not hobbyists.
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#15It's easy to be 2x productive in a language that's bound to be biased toward greenfield projects.
I maintained large C++ and large Rust codebase, and maintaining Rust codebases is much easier too.
Granted, Rust projects I worked didn't have as much scope creep as C++ projects, but I feel like that's in part due to Rust's ecosystem having better glue (cargo) than C++ alternatives
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#16Earlier quoted context omitted.
I do not wonder about the double productivity increase compared between Rust and C++. But what really makes me wonder is the comparable productivity of Rust vs. Go. I thought Go is much easier than Rust and that people could write applications much faster in Rust. I would expect that Rust takes at least 2-3 times more time to write an application, compared to Go, but then I would also expect it to run at least 2-3 ti…
I don’t mean this post to be about Go; I have never written significant amounts of Go and have no opinion on its productivity. Productivity in Rust is difficult to talk about, because of differences in opinion and what I like to call “the TCO problem.” Because Rust is hard to learn, a lot of folks assume it’s that hard all the time. Which means they assume things take just as long for a new Rustacean as they do an ex…
For anyone like me who wondered what "TCO" is: In this context "TCO" stands for "time-cost optimization," basically the idea that time is money and so you shouldn't be scared of weighing:
- an alternative that costs a small amount of money over a long span of time, against one that costs a large amount of money for just a short span of time
- an alternative that costs money (or time) up front, against one that costs a money (or time) later on
I'm still not 100% sure what "_the_ TCO _problem_" is, specifically; but it definitely has nothing to do with tail-call optimization. :)
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#17Earlier quoted context omitted.
I don’t mean this post to be about Go; I have never written significant amounts of Go and have no opinion on its productivity. Productivity in Rust is difficult to talk about, because of differences in opinion and what I like to call “the TCO problem.” Because Rust is hard to learn, a lot of folks assume it’s that hard all the time. Which means they assume things take just as long for a new Rustacean as they do an ex…
For anyone like me who wondered what "TCO" is: In this context "TCO" stands for "time-cost optimization," basically the idea that time is money and so you shouldn't be scared of weighing: - an alternative that costs a small amount of money over a long span of time, against one that costs a large amount of money for just a short span of time - an alternative that costs money (or time) up front, against one that costs…
Ooos sorry! I meant https://en.wikipedia.org/wiki/Total_cost_of_ownership
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#18Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#19Earlier quoted context omitted.
People working at Google are by definition not hobbyists.
Ok, people with "passion" then
You could just like, say what you mean rather than try and launder the opinion through insinuating things about the people involved.
If someone is passionate but that makes them more productive, why would that be a bad thing? At the end of the day, they’re still more productive?
Regardless, there’s nothing to indicate that the folks involved are new, or “more passionate” or whatever. They’re Google engineers doing their job at Google. Google has a bunch of Rust projects, some large ones too, that have been going on for years.
Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++
#20For everyone asking: 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 c…
I remember there were several pilots to rewrite some of C++ libraries in Rust at the exploration stage, keeping their behavior as close as possible. IIUC, the outcome was positive in general, consistent with the tweet's claim.