Rust developers at Google are twice as productive as C++ teams
- Reference: 1711902791
- News link: https://www.theregister.co.uk/2024/03/31/rust_google_c/
- Source link:
Speaking at the [1]Rust Nation UK Conference in London this week, Lars Bergstrom, director of engineering at Google, who works on Android Platform Tools & Libraries, described the web titan's experience migrating projects written in Go or C++ to the Rust programming language.
Bergstrom said that while [2]Dropbox in 2016 and [3]Figma in 2018 offered early accounts of rewriting code in memory-safe Rust - and doubts about productivity and the language have subsided - concerns have lingered about its reliability and security.
[4]
"Even six months ago, this was a really tough conversation," he said. "I would go and I would talk to people and they would say, 'Wait, wait you have an `unsafe` keyword. That means we should all write C++ until the heat death of the Universe.'"
[5]
[6]
But there's been a shift in awareness across the software development ecosystem, Bergstrom argued, about the challenges of using non-memory safe languages. Such messaging is now coming from government authorities in the US and other nations who understand the role software plays in critical infrastructure.
The reason is that [7]the majority of security vulnerabilities in large codebases can be traced to memory security bugs. And since Rust code can largely if not totally avoid such problems when properly implemented, memory safety now looks a lot like a national security issue.
[8]
Back in September 2022, Microsoft Azure CTO Mark Russinovich argued that software projects that might have been started in C/C++ [9]should use Rust instead. That recommendation now extends beyond greenfield projects to calls for reworking old code written in non-memory safe languages.
Earlier this year, Microsoft put out a call for developers to help [10]port its own C# code to Rust. And the Internet Security Research Group (ISRG)'s Prossimo project has been rewriting core open source elements of critical libraries (eg, NTP, DNS, TLS) in Rust for the sake of [11]memory safety .
[12]Securing open source software: Whose job is it, anyway?
[13]Rust can help make software secure – but it's no cure-all
[14]Memory-safe languages so hot right now, agrees Lazarus Group as it slings DLang malware
[15]Dump C++ and in Rust you should trust, Five Eyes agencies urge
There's been pushback from C++ creator Bjarne Stroustrup and others. In response to a November 2022 NSA [16]memo [PDF] urging memory safety, Stroustrup [17]argued [PDF] that C++, with proper tooling, can match Rust's memory safety guarantees "at a fraction of the cost of a change to a variety of novel 'safe' languages."
And in February, when the US Office of the National Cyber Director published [18]a report [PDF] on security software, some of those leaving [19]public comments observed that memory safety is a subset of broader software security challenges, and should not be viewed as an answer to everything.
Carnegie Mellon's Software Engineering Institute, for example, emphasized that all programming languages have trade-offs and the choice of programming language should come down to whether it is fit for purpose.
[20]
"Most memory-safe languages do not prioritize timing performance, and therefore are not appropriate for use cases that have strict performance and timing requirements," the software group [21]claimed .
"Also, as with any programming language, developers must learn the correct mechanics of the language, such as syntax, semantics, constructs, idioms, and tools. Otherwise, the result might be an unintended tradeoff of less memory-related vulnerabilities for more vulnerabilities or defects of other types."
While there's more to software security than memory safety, the cost advantage that Stroustrup claims can be realized by sticking with existing C++ infrastructure now faces counter-examples from Rust adopters like Google.
No loss in productivity - quite the opposite
At the Chocolate Factory, turning Go code, which is [22]considered memory safe but not as performant, into Rust has shown noteworthy benefits.
"When we've rewritten systems from Go into Rust, we've found that it takes about the same size team about the same amount of time to build it," [23]said Bergstrom. "That is, there's no loss in productivity when moving from Go to Rust. And the interesting thing is we do see some benefits from it.
"So we see reduced memory usage in the services that we've moved from Go ... and we see a decreased defect rate over time in those services that have been rewritten in Rust – so increasing correctness."
More significant, Bergstrom said, is the comparison of rewrites of C++ code 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 in Rust as well as maintain and update those services written in Rust," he [24]said .
"And so that's a really huge thing for us because C++ code is very expensive. These are large teams. It's a lot of work. There's a lot of risk."
Bergstrom said Google has a similar migration underway moving developers from Java to Kotlin and that the time it takes to retrain developers in both cases – Java to Kotlin and C++ to Rust – has been similar. That is, in two months about a third of devs feel they're as productive in their new language as their old one. And in about four months, half of developers say as much, based on anonymous internal surveys.
A bit more than half of his developers say that Rust is easier to review, according to Bergstrom.
"When we sort of look into why that is," he said, "we get to sort of the most incredible question of the survey, the one that kind of blew all of us away, which is the confidence that people have in the correctness of the Rust code that they're looking at – so in comparison to code in other languages, how confident do you feel that your team's Rust code is correct?"
The answer, Bergstrom said, was 85 percent.
"That is a massive number," he said. "I could not get 85 percent of this room to agree that we like M&M's. Eight-five percent of people believe that their Rust code is more likely to be correct than the other code within their system. … I've been through more than one language survey in my life and I've never seen those kinds of numbers before." ®
Get our [25]Tech Resources
[1] https://www.youtube.com/live/6mZRWFQRvmw?feature=shared&t=26575
[2] https://blog.rust-lang.org/2016/05/16/rust-at-one-year.html
[3] https://www.figma.com/blog/rust-in-production-at-figma/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zgnc9-ujZ30NYtuZUSLNCQAAAFM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zgnc9-ujZ30NYtuZUSLNCQAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zgnc9-ujZ30NYtuZUSLNCQAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zgnc9-ujZ30NYtuZUSLNCQAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[10] https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/
[11] https://www.memorysafety.org/
[12] https://www.theregister.com/2024/03/08/securing_opensource_software_whose_job/
[13] https://www.theregister.com/2024/02/08/rust_software_memory_safety/
[14] https://www.theregister.com/2023/12/11/lazarus_group_edang/
[15] https://www.theregister.com/2023/12/07/memory_correction_five_eyes/
[16] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/1/CSI_SOFTWARE_MEMORY_SAFETY.PDF
[17] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf
[18] https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
[19] https://www.regulations.gov/document/ONCD-2023-0002-0001/comment
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zgnc9-ujZ30NYtuZUSLNCQAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[21] https://www.regulations.gov/comment/ONCD-2023-0002-0068
[22] https://www.memorysafety.org/docs/memory-safety/
[23] https://www.youtube.com/live/6mZRWFQRvmw?feature=shared&t=27048
[24] https://www.youtube.com/live/6mZRWFQRvmw?feature=shared&t=27094
[25] https://whitepapers.theregister.com/
Re: How much of the improvement in the conversion to Rust is because it's a re-implementation
I was thinking the opposite way, the code has been rewritten, and this has cleaned up the code base. Basically, the technical debt has been reduced. The code is again clean, lean, fast and actually maintainable.
Re: How much of the improvement in the conversion to Rust is because it's a re-implementation
That's possible also, but I think and hope that much of the original code has been refactored many time over the past years.
I know one of my more pleasant tasks (really!) is to go back and look at my older code base that is still in use and see if I can make it cleaner, more effective, more error-proof.
Well, he would, wouldnlt he?
Especially in that particular venue.
Preaching to the choir has never impressed me very much, Bergstrom. Strikes me as cowardly.
Eight-five percent of people believe that their Rust code is more likely to be correct than the other code within their system.
Said the group who have chosen to do it.
I'm, not convinced that programmer's views on how good their code is tallies that well with how good it actually is. How many said "gee, my code was crap today but no concerns" and kept gong?
confidence
Was thinking along the same lines.
(1) "decreased defect rate over time in those services that have been rewritten in Rust – so increasing correctness"
That's the sort of thing that gives confidence.
(2) "how confident do you feel that your team's Rust code is correct?"
That one is tricky. If you say your code is incorrect, I am likely to believe you. But if you say your code is correct, I am more hesitant. Maybe you know some objective metric like (1) and it's all fine, or maybe there is nothing objective behind your answer. At which point I start to wonder why I even asked the question...
Re: confidence
For me switching to Rust the big surprise was not so much confidence in code I'd written but how much less stressful the act of writing code that you feel confident in is . I don't think Google's survey really captures that but it's a sort of consequence of confidence, probably one big factor behind the productivity improvement, and that in turn backs up that the confidence is not misplaced.
As it happens this week after 2 years using Rust I had to return to C++ for a bit. In just 2 days I made one horribly embarrassing integer overflow bug which passed all unit tests - Bjarne Stroustrup might argue the bug was in testing I suppose - of the kind that Rust's compiler would have flagged up immediately and forced me to make the stupidity explicit in the code to easily see, or else fix it.
I've got decades experience writing C++, reviewing other's C++, finding bugs, exploiting vulnerabilities, reversing binaries C++ compilers generate, watching each bug type unfold in full low-level glory in debuggers. And despite all that or maybe because of it I just don't feel confident writing C++ code. It's taken Rust to make me properly realise that, or at least to realise that the constant coding anxiety about subtle bugs (or even just stress about whether you're using enough of the right tooling to make safe your dangerous language) isn't necessary in order to write high-performance software.
Re: confidence
I feel my code is more correct if I write it in c++, rust or typescript, compared to if I write it in python or JavaScript.
So I would certainly self-rate my code's likely correctness higher in some languages
"More productive"
Anyone would be more productive, all the hard work has already been done. They're just translating one language to another and maybe finding a few logic problems on the way.
Rust really is easier to write and maintain
So as someone who has written large systems in C++ for 20 years (including servers, GUI apps, and embedded) and has been using C# for 10 years, Python for 15, Rust for 1, the latter three really are easier to write, read, and maintain (with one exception I'll get to) for one simple reason: C#, Python, and Rust are written with some thought to readability. C++ is performance uber alles, even if it makes the code hideously ugly and the compile errors nigh unreadable (once you add in templating).
C++ isn't perl levels of write only, but it's up there. I can go back to Python code I haven't looked at in two years (I did just last week) and oh hey, I can tell what it's doing and make changes, no problem, because it's readable. I go back to two year old C++ and it's just a slog. Part of this is the hideousness of C++'s .h files, which require you to pre-declare everything external in the .cpp file *in a slightly different syntax*, so you're tediously maintaining two slightly different sets of declarations. Part of this is because C++ is just too damn verbose. Not Java levels, but the fiddly syntax requires you to spend way too long describing *how* to do something and not *what* you're doing, even using STL. And of course there is a ton of room for accidents, because you're so focused on the detail you miss the bigger picture or vice versa and the language certainly isn't helping much. You spend inordinate amounts of time making sure you're not doing something other languages just make sure doesn't happen by default.
Now yes, you can write amazingly beautiful and readable code in perl (I've seen it) and you can write perl in python (ditto), so I'm sure you can write safe code in C++ - I certainly have non-leaky and non-crashy C++ programs (or at least they appear that way), but they took a lot of work. What really matters is what the language encourages and C++ just doesn't encourage readability or writeability - you will always have the problem where you have to look at both the cpp files and h files simultaneously for instance. And that's critical when you have more than one person working on something. And guess what? You who haven't looked at your own code for six months is 'another person'! So I find Python, C#, and Rust far more maintainable than C++. What I've done for 8 years or so is just save C++ for the very very few extremely tight and fast operations (less than .01% of the code), and everything else is C# or Python and calls the C++ when it's needed. This has been a 10x boost in productivity. Well Rust is blurring the line. I can use it for what I used to use C++ for *and* it's expressive and capable enough that I can use it for higher level stuff too. It's not good for GUIs but is just fine in the middle.
Sorry this was so long, but I've actually been in the thick of this. And what was the one exception? Well, python's lack of compile time checks makes it awkward for large systems - I'd much rather have things fail at compile than at runtime. I still love it for small to medium stuff though. tl;dr if it didn't pay so well I would never touch C++ again.
Re: Rust really is easier to write and maintain
Totally agree with your points. I have written way too much code in B (predecessor to C), C/C++, and Perl (along with many years of various assemblers.)
All of the languages that require a separate set of definitions that are independent of the implementations are a real PITA.
I'm writing mainly Python now because of the very rich ecosystem. When I see most of the libraries/frameworks available in Rust, I'll start my move.
Re: Rust really is easier to write and maintain
Ditto for me. Traditionally writing in C as the "universal assembler" as mostly i wrote hardware-specific stuff, or low level number crunching, but in recent times python is my choice as its pretty good at many things (with handy libraries in numpy, scipy, and matplotlib) and safe-ish.
As the OP said, the main issue is it is interpreted so you don't always find errors until a code branch takes them, which sucks. And yes, you should have test routines that cover every branch but in the real world that often is lacking.
Google overhead
Any new language at Google is more productive. You rewrite problems that were already solved. There are no banned features (yet). There's no hyper-complicated style and consistency guide. The reviewers are your buddies.
Rumor is that Golang was popular at Google because it avoided a lot of bureaucracy, not because it was a good technical fit.
I wonder...
In addition to the "refactoring" comments above, I wonder if this is in part because the same people writing the are also maintaining it. Once the codeset is passed down a few generations we might start to hear it creak - oh the joys of maintaining someone elses code...
I don't want to be too cynical, but over 40-odd years I remember the nice same things being said about every new language and methodology.
Yup - a fresh set of eyeballs is always worthwhile.
Hard to get some new whiz-kid to look at a COBOL-68 program, though.
I'm guessing you could ask some AI engine to examine the whole corpus of a mainframe inventory/billing/HR system and have it spit out at least the basic functions that the system was supposed to provide written in some high-level pseudo code to be turned into Rust, Go, whatever.
Mybe I should look at it. My C is very rusty now.
How much of the improvement in the conversion to Rust is because it's a re-implementation
of an existing package?
Assuming that much of the conversion is using translations of existing functions, algorithms, and methodologies. Which would have been well debugged in the earlier implementation.
I'll still guess that Rust may be slightly easier to develop for new projects given its very good error checking during compilation.