9 ms·

Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

64 points by martijnarts 2y ago

martijnarts 2y ago
Full quote: "Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++." From his keynote presentation the RustNation UK conference.
- tutfbhuf 2y ago
  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 times faster than the Go version, hence it is a fair trade-off.
  - steveklabnik 2y ago
    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 experienced one. This is generally not the case. Once things click and you’re over that hump, it feels like programming in any other language. If there are similar libraries available and I don’t need to create the world from scratch, I am just as productive in Rust as in other languages that also have those libraries, generally. But that kinda leads into the other thing I alluded to; a lot of people think of “productivity” as “whatever lets me see something quickly.” But this doesn’t capture real prodctivity, in my mind, which includes the total development time, aka, how many bugs do I have to deal with later. Rust moves a lot (but not all, of course!) of this up front. Which can feel like it slows you down (but again, with experience, I find this is actually kinda minimal), but then you save time on the back end by needing to debug less. This means that robust features end up being developed more quickly than in some other “productive” languages I’ve used in the past. TL;DR things aren’t simple, and “fast to get going” doesn’t inherently mean “productive.”
    - quuxplusone 2y ago
      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. :)
      - steveklabnik 2y ago
        Ooos sorry! I meant https://en.wikipedia.org/wiki/Total_cost_of_ownership https://en.wikipedia.org/wiki/Total_cost_of_ownership
        quuxplusone 2y ago
        Ha! I guess at least "time-cost optimization" and "total cost of ownership" aren't too terribly different. :) But there's an interesting difference in framing or worldview between the two acronyms: My assumption of "time-cost optimization" assumed that such tasks as debugging were part of _producing_ a software artifact. Our implied goal (just like in the Rust talk's title) was to maximize _production_ of such artifacts at a reasonable level of quality. The back-loaded testing and bugfixing work might go on for a while (if you made that tradeoff), but it eventually ends in a "product" (or in project failure). On the other hand, "total cost of ownership" emphasizes that our primary job isn't production but _ownership_ of software, which is open-ended and goes on forever. We have to think not only about "How long will it take to get it right?" but (mostly!) about "How costly will it be to maintain, year after year, even _after_ we get it right?"
        steveklabnik 2y ago
        Agreed! I also was like "... that's not what I meant but that does kind of work, when I read your comment." :)
  - ttfkam 2y ago
    If you write Rust where you copy all the time instead of borrow, it can save you enormous amounts of time with arguably minimal performance degradation. This can make up a lot of the perceived time disparity between Go and Rust, and leave C++ in the dust. (Yes, I know C++ can copy as well, but in my experience, it can be very difficult to teach old C++ devs new habits.) After you've profiled your working code, you can go back and optimize with less copying, more borrowing, and other optimizations where it matters. Go has the same issue. After it's working, you go back to profile, and those optimization steps can often take longer than original development. (Which is why you profile before optimizing.) With C++ you must add on time to catch all the memory access bugs and fix them, which is time you don't have to take in Rust and Go due to the borrow checker and garbage collector respectively. In Go you have to find all the spots where you didn't check the error return code or other unhandled branches, hopefully before deploying to prod. This is time you don't have to take in Rust since it catches these errors during compile. The advantage of Go is that the typical path is easier, the learning curve is much shallower, and its orders of magnitude faster to compile leading to faster dev feedback loops. On the Rust side, you've got a longer learning curve, and you really have to actively resist the urge to prematurely optimize.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
RicoElectrico 2y ago
It's easy to be 2x productive in a language that's bound to be biased toward greenfield projects.
- spoiler 2y ago
  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
Bostonian 2y ago
How was productivity measured? I doubt that teams of Rust and C++ developers were given the same projects to implement.
- martijnarts 2y ago
  They actually were given the same projects! It was anonymously self-reported.
- dralley 2y ago
  This is Google we're talking about, so maybe they were :)
- pornel 2y ago
  They must have a ton of comparative data on releasing new chat apps.
olesya1979 2y ago
[flagged]
hardware2win 2y ago
Probably hobbyists were more likely to join rust side after learning about its pros?
- steveklabnik 2y ago
  People working at Google are by definition not hobbyists.
  - hardware2win 2y ago
    Ok, people with "passion" then
    - steveklabnik 2y ago
      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.
      - asyx 2y ago
        It's bad because people that write C++ for a living got all the joy and happiness sucked out of them and since Rust is in a similar playing field regarding performance, they can't say that they need to use C++ for performance reasons and therefore would admit that all the pain and suffering would be for nothing if they let one good word regarding Rust stay uncontested on the Internet. I don't even like Rust that much but it's like Stockholm Syndrome is a requirement to have a positive opinion regarding C++.
      - hardware2win 2y ago
        I meant that people who write Rust may be more curious about tech, so they could be better devs
steveklabnik 2y ago
For 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 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."
- summerlight 2y ago
  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.
- blub 2y ago
  Do you think “Lars”, as chair of the Rust Foundation board of directors and previous Servo project member could have a conflict of interest here? Something that should be mentioned as a disclaimer when quoting his opinion on Rust vs. other languages and that would significantly water down the strength of their claims.
  - steveklabnik 2y ago
    Could? Sure, in an abstract sense. What would the motivation be for someone so senior to lie on stage about this stuff? Just because he likes a programming language? This is conspiracy style thinking. Thankfully, if Lars is lying about this, there's tons of Google folks here on Hacker News. I haven't seen anyone yet make an actual claim with any evidence that he's not telling the truth here.
constantcrying 2y ago
If you ever used Rust I am sure you already are aware of one major reason for the discrepancy, which surprisingly has nothing to do with the language. The tooling around rust is just so much better. CMake, include conflicts, dependency management, etc. either don't exist or are all much less painful in rust. There is just so much annoying stuff that you do not have to deal with when using it. There isn't really much revolutionary that rust the language does. Explicitly having to describe the behavior of memory takes getting used to, but lifts some weight of your shoulders. Other than that it has a somewhat better, and less verbose, syntax than C++. But that really is it.
- pptr 2y ago
  A lot of this tooling is available for C++ development at Google. Includes are added automatically when you use code completion. There is also a simple IDE command to add all the include dependencies to your build file. I don't know how well rust is integrated with Googles internal tooling. The golang integration is incredible, though. You don't need to touch includes or build dependencies at all. They are fully automated.
  - constantcrying 2y ago
    >A lot of this tooling is available for C++ development at Google. No, it isn't. Google even has their own build system, because obviously CMake is so bad, but it it is made for insanely large systems not ease of entry for medium/small projects. C++ slowly is adopting the language features that allow for such integrated tooling, but it isn't there yet. But right now the tooling can't exists simply because of what C++ is. The problems you can't easily solve in C++ are things like "how do I integrate this already existing library into our build chain", that is a legitimately hard question and millions of lines of code have been written trying to solve that problem. There is no equivalent to cargo for C++, there is build2, there is conan there is vspkg and the VS build system. ALL of them suck and have their own gigantic problems which will raise their head and suddenly you are struggling with include and build problems. Google hasn't fixed C++, nobody has.
    - 2y ago
deleted 2y ago
[deleted]

64 points by martijnarts 2y ago

Full quote: "Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++." From his keynote presentation the RustNation UK conference.

tutfbhuf 2y ago
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 times faster than the Go version, hence it is a fair trade-off.
- steveklabnik 2y ago
  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 experienced one. This is generally not the case. Once things click and you’re over that hump, it feels like programming in any other language. If there are similar libraries available and I don’t need to create the world from scratch, I am just as productive in Rust as in other languages that also have those libraries, generally. But that kinda leads into the other thing I alluded to; a lot of people think of “productivity” as “whatever lets me see something quickly.” But this doesn’t capture real prodctivity, in my mind, which includes the total development time, aka, how many bugs do I have to deal with later. Rust moves a lot (but not all, of course!) of this up front. Which can feel like it slows you down (but again, with experience, I find this is actually kinda minimal), but then you save time on the back end by needing to debug less. This means that robust features end up being developed more quickly than in some other “productive” languages I’ve used in the past. TL;DR things aren’t simple, and “fast to get going” doesn’t inherently mean “productive.”
  - quuxplusone 2y ago
    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. :)
    - steveklabnik 2y ago
      Ooos sorry! I meant https://en.wikipedia.org/wiki/Total_cost_of_ownership https://en.wikipedia.org/wiki/Total_cost_of_ownership
      - quuxplusone 2y ago
        Ha! I guess at least "time-cost optimization" and "total cost of ownership" aren't too terribly different. :) But there's an interesting difference in framing or worldview between the two acronyms: My assumption of "time-cost optimization" assumed that such tasks as debugging were part of _producing_ a software artifact. Our implied goal (just like in the Rust talk's title) was to maximize _production_ of such artifacts at a reasonable level of quality. The back-loaded testing and bugfixing work might go on for a while (if you made that tradeoff), but it eventually ends in a "product" (or in project failure). On the other hand, "total cost of ownership" emphasizes that our primary job isn't production but _ownership_ of software, which is open-ended and goes on forever. We have to think not only about "How long will it take to get it right?" but (mostly!) about "How costly will it be to maintain, year after year, even _after_ we get it right?"
        steveklabnik 2y ago
        Agreed! I also was like "... that's not what I meant but that does kind of work, when I read your comment." :)
- ttfkam 2y ago
  If you write Rust where you copy all the time instead of borrow, it can save you enormous amounts of time with arguably minimal performance degradation. This can make up a lot of the perceived time disparity between Go and Rust, and leave C++ in the dust. (Yes, I know C++ can copy as well, but in my experience, it can be very difficult to teach old C++ devs new habits.) After you've profiled your working code, you can go back and optimize with less copying, more borrowing, and other optimizations where it matters. Go has the same issue. After it's working, you go back to profile, and those optimization steps can often take longer than original development. (Which is why you profile before optimizing.) With C++ you must add on time to catch all the memory access bugs and fix them, which is time you don't have to take in Rust and Go due to the borrow checker and garbage collector respectively. In Go you have to find all the spots where you didn't check the error return code or other unhandled branches, hopefully before deploying to prod. This is time you don't have to take in Rust since it catches these errors during compile. The advantage of Go is that the typical path is easier, the learning curve is much shallower, and its orders of magnitude faster to compile leading to faster dev feedback loops. On the Rust side, you've got a longer learning curve, and you really have to actively resist the urge to prematurely optimize.
deleted 2y ago
[deleted]

deleted 2y ago

[deleted]

RicoElectrico 2y ago

It's easy to be 2x productive in a language that's bound to be biased toward greenfield projects.

spoiler 2y ago
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

Bostonian 2y ago

How was productivity measured? I doubt that teams of Rust and C++ developers were given the same projects to implement.

martijnarts 2y ago
They actually were given the same projects! It was anonymously self-reported.
dralley 2y ago
This is Google we're talking about, so maybe they were :)
pornel 2y ago
They must have a ton of comparative data on releasing new chat apps.

olesya1979 2y ago

[flagged]

hardware2win 2y ago

Probably hobbyists were more likely to join rust side after learning about its pros?

steveklabnik 2y ago
People working at Google are by definition not hobbyists.
- hardware2win 2y ago
  Ok, people with "passion" then
  - steveklabnik 2y ago
    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.
    - asyx 2y ago
      It's bad because people that write C++ for a living got all the joy and happiness sucked out of them and since Rust is in a similar playing field regarding performance, they can't say that they need to use C++ for performance reasons and therefore would admit that all the pain and suffering would be for nothing if they let one good word regarding Rust stay uncontested on the Internet. I don't even like Rust that much but it's like Stockholm Syndrome is a requirement to have a positive opinion regarding C++.
    - hardware2win 2y ago
      I meant that people who write Rust may be more curious about tech, so they could be better devs

steveklabnik 2y ago

For 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 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."

summerlight 2y ago
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.
blub 2y ago
Do you think “Lars”, as chair of the Rust Foundation board of directors and previous Servo project member could have a conflict of interest here? Something that should be mentioned as a disclaimer when quoting his opinion on Rust vs. other languages and that would significantly water down the strength of their claims.
- steveklabnik 2y ago
  Could? Sure, in an abstract sense. What would the motivation be for someone so senior to lie on stage about this stuff? Just because he likes a programming language? This is conspiracy style thinking. Thankfully, if Lars is lying about this, there's tons of Google folks here on Hacker News. I haven't seen anyone yet make an actual claim with any evidence that he's not telling the truth here.

constantcrying 2y ago

If you ever used Rust I am sure you already are aware of one major reason for the discrepancy, which surprisingly has nothing to do with the language. The tooling around rust is just so much better. CMake, include conflicts, dependency management, etc. either don't exist or are all much less painful in rust. There is just so much annoying stuff that you do not have to deal with when using it. There isn't really much revolutionary that rust the language does. Explicitly having to describe the behavior of memory takes getting used to, but lifts some weight of your shoulders. Other than that it has a somewhat better, and less verbose, syntax than C++. But that really is it.

pptr 2y ago
A lot of this tooling is available for C++ development at Google. Includes are added automatically when you use code completion. There is also a simple IDE command to add all the include dependencies to your build file. I don't know how well rust is integrated with Googles internal tooling. The golang integration is incredible, though. You don't need to touch includes or build dependencies at all. They are fully automated.
- constantcrying 2y ago
  >A lot of this tooling is available for C++ development at Google. No, it isn't. Google even has their own build system, because obviously CMake is so bad, but it it is made for insanely large systems not ease of entry for medium/small projects. C++ slowly is adopting the language features that allow for such integrated tooling, but it isn't there yet. But right now the tooling can't exists simply because of what C++ is. The problems you can't easily solve in C++ are things like "how do I integrate this already existing library into our build chain", that is a legitimately hard question and millions of lines of code have been written trying to solve that problem. There is no equivalent to cargo for C++, there is build2, there is conan there is vspkg and the VS build system. ALL of them suck and have their own gigantic problems which will raise their head and suddenly you are struggling with include and build problems. Google hasn't fixed C++, nobody has.
  - 2y ago

deleted 2y ago

[deleted]