Rust Developers at Google Twice as Productive as C++ Teams (theregister.com) 121
An anonymous reader shares a report: Echoing the past two years of Rust evangelism and C/C++ ennui, Google reports that Rust shines in production, to the point that its developers are twice as productive using the language compared to C++. Speaking at the 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 Dropbox in 2016 and 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. "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.'"
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 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.
Bergstrom said that while Dropbox in 2016 and 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. "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.'"
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 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.
Twice as productive because (Score:1)
Twice as productive because they don't need to think about what they are doing thinking Rust will handle everything and it's a double edged sword. One must have seen the horrors programmers wrote when Java first came out because they were thinking the same.
Re: Twice as productive because (Score:2)
Actually this was taking existing C++ developers and having them switch to rust. They also found it takes C++ devs the same time to switch to rust as it does for Java devs to switch to kotlin.
Re: (Score:1)
Java to Kotlin you do in a day or less. No idea about C++ to Rust.
I would assume someone who is good at C++ can switch to any imperative static typed language quickly.
Re: Twice as productive because (Score:2)
Not only that, some of the stuff they already did it before in C++ so now it's just a conversion, most of the logic, which takes considerable time to think of, had already been gone through before, artificially inflating the perception that C++ takes that much more effort. I'd argue the same thing would happen if it was the other way around. In fact I frequentou prototype stuff in a simpler language A before implementing the final product in the final language B (I have specific language combinations for ea
I'm surprised they're not pimping Go more (Score:1)
Re: (Score:3)
Disliking something because its too popular is a teenager move.
Go is something that is laser focused on a very specific usecase, writing servers. Its poorly suited to anything else, but for that one task its brilliantly productive.
What exactly is the reason you left it, or was it literally "its too popular" as you suggest? Because thats a strange reason for anyone who actually wants to make a living in it.
Re: (Score:3)
What exactly is the reason you left it, or was it literally "its too popular" as you suggest?
you just had to read, gp wrote quite literally "since there was no barrier-to-entry for people with zero industry experience or no computer science understanding to come along, write shitty code, and ask dumb questions". although i'm not sure about go (it seemed to me yet another unnecessary language reinventing the wheel so i never bothered with it) this is a common problem in software development.
e.g. while many software engineers despise javascript, it is actually quite a nifty language with pretty uniqu
Re: (Score:2)
The problem is the "too low barrier of entry" is a ridiculous notion and a non-argument. We're in 2024. There's an open source compiler for about every thing. There is no barrier of entry besides owning a 300$ laptop or an even cheaper used desktop.
If OP is looking for a programming language with strict gatekeeping, he's in for a world of sadness. So really, why single out Go ?
Re: (Score:2)
The problem is the "too low barrier of entry" is a ridiculous notion and a non-argument.
that's only ridiculous in your narrow view of "barrier of entry" as a matter of material resources, but you actually illustrated the point: shitty coders will produce shitty code with tools they fail to understand just like you just confidently blurted nonsense about an issue you failed to grasp. maybe the reading comprehension barrier of the internet is a bit high for you.
Re: I'm surprised they're not pimping Go more (Score:2)
Re: (Score:2)
I say this as someone that does not like Rust at all, as in mods would flag the post as flamebait if I told you how I really feel, but Rust is a better choice for most projects.
Re: (Score:2)
Being a google product, Go is abandoned by the creators, because that's what Google does.
Hello World all day long. (Score:5, Insightful)
They are twice as productive because C++ teams get all the hard work that cannot be implemented in Rust because of all the fundamental dependencies missing from the Rust ecosystem. Anyone can do hello worlds at day long and claim they are productive.
Re: Hello World all day long. (Score:4, Informative)
No, these were literally Android developers that were already writing code in C++ and asked to switch to rust as apparently Android is doing all new work in rust and only using C++ for old shit.
They found several things in this. First you've already heard, they're a lot more productive. A specific example they gave was adding an enum variant to older code, which can take a ton of validation work, whereas with rust the compiler already does a flawless job of that. Speak of flawless, another commentary they gave is that with rust, systems programming is basically flawless. They also found that with C++ code, their rate of finding newly introduced vulnerabilities is about 1 per 1000 lines of code. With rust, apparently it's zero. Not near zero, just fucking zero, as in 21% of Android is written in rust, and in all of the years they've been using rust in Android, none of that code has yet to have a single vulnerability. And finally, it also ends up being more battery efficient than C++ code.
If only more C++ developers would do research before running their mouths, we'd probably have better code already.
Re: (Score:2)
Are you directly involved?
As if it was the case it would add credibility to the statements in your post.
And if it was the case, I have a few questions: Since when Rust is used in Android? And what major parts of Android are written in Rust?
Re: Hello World all day long. (Score:4, Informative)
Or you could just look at the code examples they provided.
Re: (Score:2)
Just wanted to get to know more as it seemed you had some knowledge in the matter, however since you claim the burden of evidence is on the reader then it's easier to clarify an opinion on the topic.
Re: Hello World all day long. (Score:5, Insightful)
Are you directly involved? As if it was the case it would add credibility to the statements in your post.
I was, and am.
And if it was the case, I have a few questions: Since when Rust is used in Android? And what major parts of Android are written in Rust?
The first major component was mine: keystore. My team rewrote it in Rust in 2020 & 2021 for Android S, because it needed an architectural overhaul. It had originally been designed as a single-threaded daemon, since there could only be one secure world component and keystore's responsibility is to mediate communications with that component. In Android P we had added support for an SE-based secure world component in addition to the TEE-based one, and in Android Q we updated keystore to be multi-threaded so that operations with (slow) SE-based components would not block operations with (fast) TEE-based components... but adding multithreading to a single-threaded design is tricky. Mostly it worked, but with some limitations and we did find one livelock that had been introduced and required an ugly workaround. Also, we wanted to move away from flat files for keystore's storage.
So, in mid-2020 we started a rewrite using a multithreaded architecture, sqlite storage and building it in Rust. The project took three engineers about four months, plus there was another small team of Googlers and contractors building Rust support for Android. For example, implementing Binder tooling (Binder is the primary RPC mechanism used in Android, both between system components and between system components and vendor components). There were some initial concerns about enormous performance regressions. These turned out not to have anything to do with Rust, though, but with sqlite. Our particular configuration and usage patterns had triggered a latent sqlite bug. Google has a support contract with Richard Hipp's (author of sqlite) company and they were able to quickly identify the bug and send us a fix.
And that sqlite fix has been the only significant bugfix keystore has received since it was rewritten. There has been some additional feature work. There have been no concurrency or memory bugs. Also, no significant logic bugs, though that's clearly got nothing to do with the language.
Since the outstanding success of the keystore rewrite, there have been some other security-sensitive components rewritten in Rust. In general, rewriting stuff is a bad idea and typically injects more bugs than it squashes, so it only makes sense for things that are particularly security-critical or things that need a rewrite for other reasons. Another major component that has been rewritten in Rust is the bluetooth stack (not my area, so I don't know a lot about it). The BT stack was crufty, broken in many ways and a source of constant serious security vulnerabilities.
Beyond that, the directive since 2022 (IIRC) is that all new native-code components should be written in Rust. C++ can still be used, but using it requires justification of the choice and "We don't want to learn Rust" isn't a valid justification. Though, AFAIK, no one has even tried to make a case for writing something new in C++, because Rust is nice.
I don't know where the 21% figure quoted by ArmoredDragon came from. I haven't seen it before, and it seems very high to me. Excluding the kernel and libc, most of Android is written in Java, but there are still millions of lines of C++ and will be for a very long time since there isn't any reason to rewrite stuff that is working.
As for how the engineers feel about it... I don't know anyone who's made the switch to Rust who wants to go back. That includes me. I started writing C++ in 1990 and I have really enjoyed writing C++ through all of it's revisions. But I find Rust nicer, safer and more efficient. The compiler is slow, but it's far from the slowest part of my edit/build/test cycle, so that mostly doesn't matter. It's a bit painful to interface with C++ code; you
Re: (Score:2)
A specific example they gave was adding an enum variant to older code, which can take a ton of validation work, whereas with rust the compiler already does a flawless job of that.
That seems like a contrived example. With clang, the compiler already does that, too, assuming you're using switch statements. Just add -Wswitch-enum and -Werror.
Re: Hello World all day long. (Score:3, Insightful)
Why don't you just watch the actual presentation? They gave a long, detailed explanation complete with code examples in both languages.
Re: (Score:3)
Where is the presentation? The link in TFA goes to an 11 hour long YouTube video. Is it in there somewhere?
Re: (Score:2)
Re: (Score:2)
I'm asking if you can narrow down the 11+ hour long video to the relevant section.
To be honest, if you answer is "watch this 11+ hour video in its entirety", it's not a very good argument. You should be able to provide at least one example for us, and then maybe point to the video as a more in-depth discussion of the issues.
Re: (Score:2)
I'm asking if you can narrow down the 11+ hour long video to the relevant section.
OMG, the link is coded to start when Lars Bergstrom talks about Rust about 7:22 hours into the presentation. So I take that to mean you didn't watch the presentation at all before complaining about the presentation.
To be honest, if you answer is "watch this 11+ hour video in its entirety", it's not a very good argument. You should be able to provide at least one example for us, and then maybe point to the video as a more in-depth discussion of the issues.
But you didn't watch it all before you started demanding answers which were provided. Let me guess: you couldn't be bothered.
Re: (Score:2)
Re: (Score:1)
They *asked* to switch to Rust. Now, listen, in a company where people are thrown out if they don't do AI, if you go and ask how productive they feel” (which is how they measure) with a tech *they chose*, what sort of answers do you think you'll be getting?
Re: Hello World all day long. (Score:2)
False and false. Watch the damn presentation before running your mouth, it specifically addressed everything you just said.
Re: (Score:3, Informative)
If only more C++ developers would do research before running their mouths, we'd probably have better code already.
If only more Rust developers would think before they speak, we'd have a much more civil and friendly discussion.
That's the problem with Rust developers, they lord over others and when someone confronts them, they instantly degrade to bro tactics and accuse the other side of being barbarians. Just take your language and get out of here already. I'd rather stop coding altogether than touch your language with 500 ft pole for nothing more than the toxicity of the people pushing it.
Which is a shame, because
Re: Hello World all day long. (Score:4, Interesting)
If only more Rust developers would think before they speak, we'd have a much more civil and friendly discussion.
In the early days of when I'd talk about it here the replies from C++ devs were always to the effect of "hurrdurr only bad developers ever write C++ code with memory errors, so all rust devs are just unskilled" or "hurrdurr there's an unsafe block in a core library so all of rust has no memory safety so the whole language is pointless!"
If you don't believe me, go read posts from iggymanz, the evil atheist, or Uter Von Linkedlist, aka angel o' sphere.
That's the problem with Rust developers, they lord over others and when someone confronts them, they instantly degrade to bro tactics and accuse the other side of being barbarians. Just take your language and get out of here already. I'd rather stop coding altogether than touch your language with 500 ft pole for nothing more than the toxicity of the people pushing it.
Actually if you knew anything about the rust community you'd know better than that. Really anywhere you go -- discord, reddit, irc -- if you ask newbie questions, nobody is going to just say "rtfm" or link to the first chapter of the rust book or some shit like that. They're actually really helpful. In fact, you can likely even give example code from another language and ask if there's an analog in rust, and they might even provide a code example.
This is basically the opposite of the experience I had with C++. Basically it was either buy an expensive book, take a college course, or some other crap like that even if you only had a passive interest and weren't interested in investing any actual money into it.
In fact when I learned rust, I didn't even have any intention of being a software developer. Literally all I did was install rustup, install vscode, and follow a short tutorial. Everything else just came gradually. Two years later I was already getting paid more than 90% of other developers...in what is my first software development job. All I knew before that was a single year worth of C# and beanshell.
Which is a shame, because better memory management *is* a good thing. It's just ruined by people who cannot get along with others.
That's interesting, because the way Bjarne Stroustrup talks it doesn't matter because "there's more to safety than memory safety". Though when you listen to him talk about memory safety, it looks like he's only talking about temporal safety, which is basically unobtainable in C++ without making a big sacrifice that just isn't worth it. Everything else he talks about for safety, including that, is already provided by rust. Examples: resource safety, type safety, data race safety, null pointer safety, bounds safety, and many others. Know what else? He only has concrete plans to address resource safety and bounds safety. Everything else is either impossible with C++ or, like for data race safety, he only has a vague idea but no plans for any kind of ironclad safety guarantees.
Yet still, despite all of this, he made a "call to arms" (his own words) speech insisting that replacing C++ code is absolutely unnecessary and urging people to basically fight against it. How's that for getting along with others? The language's own founder won't even do it.
Re: (Score:3)
Re: Hello World all day long. (Score:3)
Re: (Score:2)
Re: Hello World all day long. (Score:2)
Re: (Score:2)
If only more Rust developers would think before they speak, we'd have a much more civil and friendly discussion.
In the early days of when I'd talk about it here the replies from C++ devs were always to the effect of "hurrdurr only bad developers ever write C++ code with memory errors, so all rust devs are just unskilled" or "hurrdurr there's an unsafe block in a core library so all of rust has no memory safety so the whole language is pointless!"
If you don't believe me, go read posts from iggymanz, the evil atheist, or Uter Von Linkedlist, aka angel o' sphere.
That's the problem with Rust developers, they lord over others and when someone confronts them, they instantly degrade to bro tactics and accuse the other side of being barbarians. Just take your language and get out of here already. I'd rather stop coding altogether than touch your language with 500 ft pole for nothing more than the toxicity of the people pushing it.
You are doing exactly what they are complaining about, dismissing complaints from atop an ivory tower. Rust has an evangelical cult problem that really pisses people off.
Re: Hello World all day long. (Score:2)
Here's the original post in this thread:
They are twice as productive because C++ teams get all the hard work that cannot be implemented in Rust because of all the fundamental dependencies missing from the Rust ecosystem. Anyone can do hello worlds at day long and claim they are productive.
Now tell me, what is it that I said that makes you think I'm in some kind of ivory tower, and this guy isn't?
This should be good.
Re: (Score:2)
> I'd rather stop coding altogether than touch your language with 500 ft pole for nothing more than the toxicity of the people pushing it.
Imagine locking yourself out of running water because the water company had a few annoying people working there.
Re: (Score:2)
Quote: " all new work in rust and only using C++ for old shit."
LOL. Let me clarify one thing, without that "C++ ... old shit" that "all new [Rust] work" would not work at all.
So... at the end, writing code that would not work as intended WITHOUT C++ ain't "productive" to me.
It's ego (Score:3)
I've noticed this in C/C++ devs since at least the 90s. Coding in C/C++ is seen as a Hard Thing To Do, and becomes a foundation of their self esteem. These people get quite arrogant and refuse to let it go because it means kicking that Jenga block out from underneath their towering egos.
I quite like that Rust is disrupting these little fiefdoms. C-like languages have had 30 years of memory unsafety and it's been a shambling disaster. Let's turn the page.
Re: (Score:2)
Re: (Score:2)
Programmers today are no longer real programmers. They are telling an "AI" (the compiler) what they want done, but the specifics of it all escapes them.
Are there advantages? Sure. But it is no longer real programming. It is lazy programming that could end up with some undefined behavior that will be impossible to troubleshoot... because the average programmer can barely handle pointers in their heads, much less the incredibly detailed specifics of dealing with hardware rationally.
Yeah, go ahead and have eve
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Which have you found missing? So far everything I've looked for has had a crate for it, though of course not things with the breadth of Boost or the depth of Eigen.
Re: (Score:2)
C++ programmers do sometimes solve really hard problems.
But mostly, they just make programming harder than it needs to be be.
Re: (Score:2)
Use Ada (Score:4, Insightful)
Ada users are mainly rolling their eyes at the Rust fad. And the gurus are happy to point out where Rust fails. But Rust is the right direction. It boggles the mind that we are now 1,000 years into using unsafe languages and there is finally some attention to the problem in the mainstream mindset. Oh, crap, this is going to get flagged as flamebait. Sorry. But still....
Re: (Score:2)
Re:Use Ada (Score:4, Insightful)
Re:Use Ada (Score:4, Insightful)
I looked at ADA a few years ago out of curiosity, and found itt interesting as a secure language.
But I don't like some of the strict syntax rules and noticed a bit of feature creep with the addition of OOP support, and I had no real project to work on so I didn't pursue it further.
Rust is just as interesting, but I see the same drawbacks and I see it going the way of C++ by adding new features on it all the time and abandoning simplicity.
C might need more attention to avoid bugs, but nothing beats its flexibility and simplicity. I really like it.
Re: (Score:2)
It boggles the mind that we are now 1,000 years into using unsafe languages
Um, what?
Unless you're including human language in that time frame, I think you should double check those numbers....
Re: (Score:2)
Re:Use Ada (Score:4, Funny)
Um, what?
People who don't understand hyperbole should be publicly eviscerated in the town square and have garlands hung of their entrails to serve as a warning to others.
Re: (Score:2)
Re: (Score:2)
That's not very hyperbolic.
Try: you should put a sock in it so hard it flies down your esophagus and bursts forth from your chest like an undergarment of silence.
Re: (Score:2)
Um, what?
People who don't understand hyperbole should be publicly eviscerated in the town square and have garlands hung of their entrails to serve as a warning to others.
Metal. /Nathan Explosion
Re: (Score:2)
Re: (Score:2)
>People who don't understand hyperbole
It wasn't hyperbole.
Rather, he used excel to calculate, and, well . . .
Re: (Score:2)
Re: (Score:2)
A bit, but defensiveness isn't the best way forward.
SPARK is the one that basically proves that your code matches the conditions. They apparently added pointers to the SPARK subset as inspired by Parasail and Rust.
https://blog.adacore.com/using... [adacore.com]
Re: (Score:2)
Ada users are mainly rolling their eyes at the Rust fad.
Ada's security guarantees were mainly for static programs. It didn't support anything reasonable for dynamic memory. They finally added it a couple of years ago, by adopting Rust's model of borrowing and scopes.
New code vs old code (Score:5, Insightful)
I suspect a significant difference is the Rust developers are probably working on something newer than the C++ developers. The quickest things to switch to Rust will be the smallest/newest products. The large, creaky, 1-billion-edge-cases C++ code is going to be the last stuff moved.
First, working on newer code bases is much more productive (see 1-billion-edge-cases)
Second, working on newer code bases is usually more interesting. Which means more of the better developers are going to successfully push to get on those projects. The fact that it's in a language that's getting extra buzz at the moment is going to accelerate that.
Better developers on a better code base are going to have a leg up on productivity, regardless of the language used. So while I don't doubt Rust is "more productive", I am going to doubt "double".
Re:New code vs old code (Score:4, Informative)
Re:New code vs old code (Score:4)
I'm not familiar enough with Rust. In the timepoint you linked the guy talks about using enums to replace flags being ORed. I have not found what Rust construct was used. Can you please provide a link?
In particular, how are Rust enums different than C++'s newer enum classes?
Re: (Score:2)
It's probably less specifically about enums and more about pattern matching.
In C++ your enum has 5 possible values. Somewhere in your code you have a "switch" and need to check all possible values. Add a new enum value and you won't get a compile error.
In Rust you use "match", which will cause a compile error if there are any possible values that you aren't handling. Add a new enum value, and on next compile you'll get a nice list of places that need to be updated.
Re: (Score:2)
That's exactly the behavior of enum classes in C++ (since C++11).
I am getting the distinct feeling that these arguments are just people who don't know C++ well and people who don't know Rust well shouting at each other.
Re: (Score:2)
It is absolutely not the behavior of enum classes, switch, or the combination of the two in C++, though compilers may generate warnings. See example [godbolt.org] for the problem pattern matching solves.
I agree that in general the Rust community has a tendency to argue from a place of tribalism rather than experience. I don't view this as a problem specific to Rust, but moreso newbies succumbing to confirmation bias or choice-supportive bias and parroting o
Re: (Score:2)
You are technically right, in that this is a warning rather than an error. In fact, you used compilation flags no one ever uses to make your point (no warnings at all). That goes back to a core ideological, and quite purposeful, difference between the languages, where C++ wishes to help the programmer avoid errors whereas Rust wishes to prevent the programmer from making them.
In practice, I think this is a distinction without a difference. The tools Rust provide you on that front are available to you with C
It's google what do you expect. (Score:2)
They do weird things and get weird results.
So, OK, I followed the link and even the first example seemed to confirm my suspicions. The "idiomatic" C++ code is a tangled mess. There's no need to do a shitty job of writing state machines in C++.
This isn't to say that Rust isn't a good idea, but the big win of it is that it largely prevents the kind of incredibly nasty latent bug that rears its head in 3 years causing an awful CVE and a massive fuckton of work. And really horrible threading bugs which are almo
Re: (Score:2)
>they found the most value in with idiomatic Rust because of enums rather than layered cases and conditionals
Perhaps if they had written idiomatic C++ code instead of idiomatic C code, they wouldn't have such a problem understanding it.
The presenter also seems to be (or pretends to be) unaware of -Wswitch-enum.
Re: (Score:2)
That, and the compiler really is slow. Understandable given the extra work it does, but I am imagining this as a productivity effect: https://xkcd.com/303/ [xkcd.com]
Re: (Score:2)
In practice, the slow compilation does not hurt your productivity as much as one would think.
The linting is very reliable. So we just don't bother with compiling very much.
Re: (Score:3)
There are excuses for everything.
If the code is new: Rust is only productive because it is just a new project.
If the code is old: Rust is only productive because it's just a rewrite, of course it will be clean and less buggy.
Rust is just built on better foundations than C++. 40 years from now, Rust may feel archaic and it may be time for another shift. But for now, it is the best choice, at least technically.
Rust will open systems programming to a lot more programmers who would have otherwise stayed away fr
Re: (Score:2)
Re: (Score:2)
Is Lars Bergstrom talking about embedded processors?
No one is denying that C++, and especially C, have the entrenchment advantage.
I am familiar with this argument, it is better made with C than C++:
https://slashdot.org/comments.... [slashdot.org]
"That reason often seems to be entrenchment and simplicity.
There are more C developers, C is available for most platforms and it is easy to create a compiler for a new chip. It's a small spec language.
These are certainly pragmatic considerations."
Re: (Score:1)
They do not write 2x as much code in the same time. But no doubt they can implement 2x as many features.
Bottom line it all adds up, e.g. compilation circles.
Easier debugging if you do not have to step into STL code etc.
Migrating? (Score:3)
Speaking at the 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.
I'm not much of a programmer so I may be totally on the wrong page here. But if the devs are migrating from those other languages to Rust, does that not mean that the fundamental rules, business-specific logic, UI basics if applicable, etc, are already largely worked out? Aren't Rust programmers leveraging work already done by the Go and C++ developers? If so, then of course they're "twice as productive".
Re:Migrating? (Score:4, Informative)
I'm waiting for April 2nd ... (Score:2)
Re: (Score:2)
When properly implemented? (Score:2)
This confuses me. Surely _any_ language, when properly implemented, will totally avoid memory security bugs.
I'm not a Rust programmer, and probably don't appreciate it. I'm guessing that it's just harder for other languages to properly implement avoidance of these bugs.
Re: (Score:2)
This confuses me. Surely _any_ language, when properly implemented, will totally avoid memory security bugs.
That might be true if every line of code was given all the time, skill, and money to make sure it was properly implemented. For some languages, there is enough to hang yourself.
I'm not a Rust programmer, and probably don't appreciate it. I'm guessing that it's just harder for other languages to properly implement avoidance of these bugs.
Some of these languages were not designed with these safeguards in mind. Rust was.
Re: (Score:3)
Yeah, well I believe that "properly implemented" is the guiding principle when coding. How else would you avoid bugs? But I think it's telling that they had to add those words in that sentence.
TL;DR
Maybe it's easier in Rust, many seems to state this, it might be true. It's definitely not easy to do in c++, but c++ is an old language and back then the main concern was hardware constrain. Coding used to be an art form, sometimes it became too artsy when coders wrote compact code with many intended side effect
Twice as productive (Score:2, Insightful)
Re: Twice as productive (Score:4, Interesting)
Yeah, doesnâ(TM)t everyone? The problem is itâ(TM)s very easy to be a bad C++ developer, and thereâ(TM)s a long twisty road to travel before you can be a good one.
Rust is similar, except the bad Rust programmers will spend more of their time battling the compiler and less of their usersâ(TM) time discovering runtime bugs caused by avoidable programming errors.
Re: (Score:2)
Re: (Score:1)
It might be due to the nature of the code. (Score:1)
How productivity is measured (Score:4, Insightful)
Now, quoting from the guy, the developers chose Rust as technology, and the company went to developers and *asked them how productive they feel* in a technology they chose. Now, Google is not the ideal workplace that people thought it was 15 years ago. Google is a company that prepares itself for the next firing round. Their work is probably not AI related, because if it was they would've done something in python. What will the answer be? What would you answer, especially knowing that your productivity isn't measured in the quality of what you release because *there's nobody to measure that*!!!
I really hate the trend of strong-arming Rust as if it was safe. It isn't. You can mess up just like in C++ or C, the unsafe keyword doesn't change the accessibility of ways of messing things up. It is possible that a lot of the code that you have out there written in Rust is better because Rust was adopted by more senior developers because they are the only ones who accept fighting with the compiler so much. Plus, Rust codebases don't have to struggle with 80s, 90s and 00s mindsets in the libraries they use because, well, it didn't exist back then. So I get what's going on there. I wish Rust developers would do more work with their code than with their mouths, because their choir is cacophonously deafening.
Re: (Score:1)
LMAO (Score:1)
Java had the best chance at unseatin
Twice as Productive (Score:3)
So, they are twice as productive at rewriting already debugged and working C++ code into Rust code as rewriting C++ into C++?
Or are those C++ teams doing something else?
There is a significant difference in speed in doing something new vs rewriting an existing app in a new language.
Re: (Score:2)
Or are those C++ teams doing something else?
It's generally the same people, only now they've learned Rust as well as C++.
Re: (Score:2)
Yes, but it is what they are doing with it that counts.
If the majority of Rust work is rewriting C++ code that's a lot easier.
Re: (Score:2)
Yes, but it is what they are doing with it that counts.
If the majority of Rust work is rewriting C++ code that's a lot easier.
It's not. Even the rewrites are redesigns and rearchitectures, to accommodate and enable new requirements. There's rarely any point to rewriting the exact same thing.
Why didn't Google (Score:2)
Please define (Score:2)
"productivity". Are you talking lines of code? Or coded, tested, debugged, and comprehensible - that last word means that in a year, when you're not around, some poor sucker gets told to enhance, or fix a bug, that you left?
Productive... (Score:2)
Oh Boy (Score:2)
Re: Rust guys and car commuters (Score:2)
Well here's the kind of life decisions C++ die-hards make:
"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.'"
Re: (Score:2)
I have fond memories of Activision being weirdly proud of builiding memory management into the game engine for Heavy Gear 2 [gamedeveloper.com] instead of just crashing to desktop, and it being somehow revelatory and revolutionary.