android's data for rust adoption shows that rust code has ~5000 times fewer memory safety vulnerabilities per MLOC. that's a lot more than i expected, actually! https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html

(you might say that you're better than google's devs, but are you *five thousand times* better? i'd be skeptical.)

Rust in Android: move fast and fix things

Posted by Jeff Vander Stoep, Android Last year, we wrote about why a memory safety strategy that focuses on vulnerability prevention in ...

Google Online Security Blog
@whitequark this one weird trick of not making unsafety be pervasive turns out to work quite well
@dysfun @whitequark the vulnerabilities aren't in the exciting hot optimized special code, they're in the boring cold no-one-ever-looks-at-it-code, which is why unsafe rust works so well still
@whitequark Clearly the data is distorted by the outlier Bob, who has 100 vulns per line
@joseph_garvin this would be an amazing code golf goal: fit 100 vulns in a nornal, 120 column line of code. I'd love to see someone try
@whitequark @joseph_garvin first rule: using perl for this is cheating
@whitequark @joseph_garvin my first thought is: eval(askChatGPT("code for one website please")
@whitequark Does the same code in a header resulting in slightly different real exploits by giving attackers a Write-What-Where gadget count?
@malwareminigun can you rephrase?
@whitequark Imagine there's an inline function in a header, that has a bug leading to the aforementioned WWW. That header is # included by a hundred other components. Since each component is different, the practical impact of that WWW will be different. But all hundred components need to re-built and re-shipped to fix it
@malwareminigun clever, i'll allow it this once
@whitequark (Though I guess I'm not sure how realistic a 1 line WWW is)
@joseph_garvin @whitequark I AM SMARTY WIZARD 5000X PROGRAMMER!

@whitequark Didn't know they were using Rust in Android! I find it mildly amusing that it's not Golang (although I guess it wouldn't surprise me much if they were also using that).

I guess it makes sense if it's already being used in the kernel?

@snowfox they wanted a C++ replacement for OS userspace and Go isn't really that; I think they actually started using Rust in the kernel later

@whitequark

> (you might say that you're better than google's devs, but are you *five thousand times* better? i'd be skeptical.)

Yes. Not because I"m amazing, but because every single piece of code I've ever seen from a Google dev was among the absolute worst code I've ever seen.

[...with the exception of Go.]

@pixx dunno, there is beef i have with Google on _many_ things but the quality of C++ in V8 and Chromium isn't one of them (and I think the $1M-range exploit prices reflect that as well)

@whitequark ...having looked at the Chromium source a while ago... I'll politely disagree.

(It's certainly not the _worst_ I've ever seen, but it's far from _good_.

I mean, it's C++, for starters.)

@whitequark Thanks for highlighting this bit, prompting me to finally read TFA. I'm impressed and hope this study will finally unstick some of the nay-sayers. I don't ever want to write C++ again (and I _almost_ never write C except the rare case where minimal object code size is critical).
@whitequark I know nothing about nothing here, and don't have a horse in this race, but one doesn't need to be 5,000 times better to generate 5,000 times fewer errors. I could imagine scenarios where one was just the merest "I know to check for this one common thing" scintilla better.
@tartley yes, for sure; you'd have to actually look into the details of errors to know how much better one truly needs to be (and even that whether this is even something one can really measure is very questionable)
@whitequark Tbh I'm even more impressed by the "-20% effort reviewing and -75% rollbacks" numbers. That directly translates to time saved producing _every line of new code_.
@endospore oh yes for sure. I just expect people to be much less sympathetic to "Google can churn out more code more safely" these days, for very good reasons (and it does depend even more on who your programmers are and how they're trained and which environment they're in, so IMO it probably translates less to others)