Key take.5 million Rust LOC One potential memory safety vulnerability found Rust is 0.2 vuln per 1 MLOC. Compared to C and C++ : 1,000 memory safety vulnerabilities per MLOC.Note that Google still doesn't have official support for using Rust in Android userspace, though.
Despite all pluses on the blog, NDK only supports C and C++ tooling, same on Android Studio, and it is up to the community to do the needful work, if anyone feels like using Rust instead.
Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using Rust or anything else so long as it plays by the rules.
Some people rather reach out for first party support, instead of filling in the gaps for the big boys.
By first party support, would you be expecting a Rust toolchain shipped in the NDK, or maybe Rust bindings shipped in the NDK?
I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io.
Or maybe they should ship scripts that shell out to an existing Rust toolchain.
I expect Rust being documented here,
https://developer.android.com/ndk
I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust.
I expect all NDK APIs to have Rust bidding crates.
I expect that Android developer forums also care to support devs using Rust.
And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and C++.
The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.
Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.
The issue with most codebases is nobody thinks about starting out with acceptance testing system.
The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on.
This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And things like memory and cpu runtime constraints are a part of this.
If you have this, you basically replace what the Rust compiler is doing for you with tests. Memory leaks are caught. However, as a benefit, you also can verify changes in the dev cycle with things like performance degradation, all in the same system.
We all knew rust was safer. It was the 1000x number that surprised me.
Which is more that rust isn’t that safe in my mind, it’s that bugs are that prevalent. I never would have guessed that.
That 4x rate is very impressive too.
Great seeing all this data from a large big complicated codebase.
I found it interesting that the rollback rate remained more or less constant despite size differences.
If they use Rust for new code and C++ changes are all in old code, this could be explained just by older code being more risky to change.
Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already.
If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.
At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
I’d say the same applies for Swift vs ObjC.
Let’s end the C era.
Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever.
Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default!
</rant>
I don’t disagree with anything you said.
Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.
While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using
I think they're comparing new code in Rust vs new code in C++.
This is the bomb that sank C++ in 2026.
Have fun justifying that Rust is "also" unsafe, with the right tools you can achieve the same in C++, if you're a great dev you can do even better, etc.
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better.
It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write.
I would like to use rust to write android apps. I don't really like the whole android studio java thing.
> I think cargo is better than cmake
I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages).
I absolutely agree if you aren't Google though.
Google3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing.
If I were to go to another company I’d promote using either of the above.
What does Android do for Rust?
Android uses Soong: https://source.android.com/docs/setup/build
Proprietary code uses the internal version of Bazel: https://bazel.build/
Yeah my understanding is that google has some sort of God program they use that can compile anything and has 10,000 command line options.
>I think cargo is better than cmake
That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has.
There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track.
In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMake is to wish you didn't, that way someone else would have to maintain it.
You seem to forget about autotools. Cmake is ugly but I'll take it over autotools.
As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful.
At least it knows how to use ninja though.
I cannot like Rust syntax, sorry.
For me the ideal syntax is C/Go, just to be clear what I like.
But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...
All three have very similar syntax when compared even to something like Python or Ruby, let alone ML or Haskell. Seems like a spurious complaint.
I don’t disagree, that’s part of why I like Swift so much. Rust looks very C++ to me.
But if I was working in C++ and had a choice of C++ or Rust, I’d go Rust based on this.
Agree! Swift I forgot to mention. What a nice and elegant language.
No need to like it. It isn’t brainfck and does the job.
in the beginning I also hate it, but now is fine.
I dislike Rust, but I would definitely prefer it over the "Android Studio Java / Kotlin thing", for sure.
Id like to see dev time in Rust vs C++, but generally, I sort of agree. If you use modern C++ with all its features, Rust is generally a better alternative.
That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.
I personally have zero interest in these feud wars. I'm only glad there are more quality options for Devs to develop safer system tools.
I mean we know for sure Rust is unsafe there is whole bug tracker dedicated to all the ways it's unsafe. My favorite is that you can cast any lifetime to static no matter how short it actually is in 100% safe Rust.
(doesn't mean it's not an improvement on C++)
This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.
Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&editio...
I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860
Yes, that's an existing soundness hole in the compiler. You won't accidentally code it up yourself though.
If the bar is "deliberately malicious code results in a segfault", get back to me when they fix
EDIT: and even that's being charitable; the Rust issue is viewed as a compiler bug which should be fixed.memcpy(0x10000, 0x20000, 0x10);
The unsound bug tracker is were my heart gets all warm and fuzzy in Rust land.
All the ways to coerce and poke the implementation of what should be safe constructs to produce unexpected garbage - and people spending time fixing the issues because they are treated as bugs.
It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.”
https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...
This isn't control for confounding factors.
For example: folks are more likely to rewrite stuff that is well-understood, and stuff that is well-understood is going to have shorter review times and lower rollback rate.
That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more rollbacks, and less likely to be rewritten.
The first chart does in fact a compelling reason to believe the effect is not that at all. If the "easy" code was predominantly being rewritten you would expect to % new memory unsafe code and % memory safety vulnerabilities to scale at different rates as the difficult to work on areas remained in C and kept causing new memory vulnerabilities.
Personal experience also provides a compelling reason, my experience is absolutely that people are more inclined to rewrite the things that are causing trouble in a new language.
It's not a blinded randomly controlled trial of course, it's observational data. You can't be completely sure there isn't a confounding factor that explains the data, but it seems far more likely than not that it is a real effect.
I would expect memory safety vulns to be dropping in most C/C++ projects due to better practices
You would be severely disappointed.
This contradicts what Google has reported about their own code, which is that most vulnerabilities are in new code
I don't see a contradiction between the statement that vulns in C++ code are generally on a downward trajectory, and the statement that most vulns are in new code.
That is somewhat mitigated by grouping comparisons of S/M/L change sizes.
It would be interesting to group changes by line-deletions, say to indicate rewrites (and size of them)
This article is mostly about new code.
> That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more rollbacks, and less likely to be rewritten.
I'd say that this is likely the most likely to be rewritten actually, because high test coverage is a massive enabler in such a rewrite, and because having a project that “only a few greybeards grok” sounds like a big organizational liability.
That being said, and while I'm pretty convinced that Rust bring massive benefits, I agree with you that these measurements shouldn't be taken as if it was a rigorous scientific proof. It's more of one additional anecdotal evidence that Rust is good.
> It's more of one additional anecdotal evidence that Rust is good.
But that means it's likely to be the worst kind of science:
- Group of people agree that Rust is good. This is a belief they hold.
- Same group of people feel the need to search for argument that their belief is good.
- The group does "science" like this.
And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion.
> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion.
Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?
In science, you go out of your way to control for confounding factors.
This isn't that.
> In science, you go out of your way to control for confounding factors.
There's tons of observational science done in a very similar fashion to the article where there is simply no way to control for confounding factors for the same reason that there is simply no way to properly control for it in the data available.
Having been close to someone who went through the PhD process to a career in research, this is a sadly common but romantic and incorrect view of science as practiced in the world today.
I use rust for gamedev (not bevy). I'm unlikely to consider anything else exactly because of stability and throughput.
At this point I feel like it's no longer an uphill climb to get Rust into foundational, mission-critical code adoption. The benefits are so obvious. Maybe it's just a lingering religious war?
In any case, I'm glad we're seeing more and more evidence and case-studies of why "rewrite it in Rust" isn't just a meme.
But the approach here is "write new code in rust", not rewrite.
Eh, I don't think it's actually one or the other. Google has taken on rewriting some more problematic components in rust. See for example:
Binder kernel driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Media codecs: https://www.androidauthority.com/android-16-in-process-softw...
This is also happening at Microsoft:
> Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library
https://www.microsoft.com/en-us/research/blog/rewriting-symc...
Google rewrote Android's Bluetooth stack in Rust.
Also mentioned:
Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust
Sure, but at a macro level the approach is still to "rewrite" Android subsystems in Rust. Just slowly.
The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say "Rust is too hard!" and they give up.
But if you stick it out, as Google has, the dividend is that more often than with other languages, you are not paying these costs continually but instead reaping dividends on the long run.
First of all, Rust has the Haskell-like property that (as long as the logic is sound) if your code compiles, it usually runs just fine. This is why testing speeds up, because all of the edge cases that are explored during testing were already accounted for by the compiler.
It also translates into easier refactoring, where you can make sweeping changes in the codebase and feel confident that you can put it all back together again.
And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!". Fast is a feature, and your users benefit from it every time they run your code.
It's hard to find that nexus of features in other languages. Usually they are just as fast and hard to write as Rust, without the safety guarantees. Or they are just as safe as Rust, but without the speed. And that's why Rust has hit a sweet spot where other languages can't quite get it.
Yeah, I use Rust at work and it's a boon.
It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model.
One of the main features of Rust is the community, there are so many great packages
Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type theory
I'm glad you said that because that's exactly where my research is ^_^
https://andraskovacs.github.io/pdfs/2ltt_icfp24.pdf
I think that something like this is the endgame practical programming language
The graphs aren't showing up for me on the site unless I click on them
> Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust, making it easier for Chromium engineers to deal with data from the web
I find this surprising, isn't Wuffs[1] (also made by Google) an even better fit for this particular use-case? (It has compile-time spatial memory safety, where Rust has compile-time temporal safety but runtime spatial safety, with bound checking).
Obviously for general-purpose system programming, Rust is a no-brainer and I'm happy to see Google pursuing their rustification of Android.
I don't find it surprising, just from barriers to adoption: "Wuffs programs take longer for a programmer to write, as they have to explicitly annotate their programs with proofs of safety" is a hard sell (even if it has obvious value) and "you have to learn and integrate yet another language just for parsing files" is a hard sell too.
Which isn't to say that it shouldn't be adopted (having not used it I really don't know), just that it's not surprising that it's having difficulty gaining traction.
I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both.
Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code written in 2022 actually increased, with rust not really having gained any significant momentum.
How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".
Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
> How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".
The first graph considers <memory unsafe> vs <memory safe> languages, while the second graph considers C++ vs Rust. There's more languages than just those two in the first graph.
Moreover the first graph is in percentage terms, while the second graph is in absolute terms.
In 2022 it appears a bunch of memory safe non-rust code was added. Java/python/...
> Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
That's a perfectly human phrasing lol.
I’m a little perplexed why every time something in rust compiles, there’s a blog post about it. I was under the impression Ada, especially when using provers, has been around much longer and is more robust. I just can’t decide if the massive Rust evangelism budget is a red flag or just a curious sociological case study, but I wish I knew the truth.
> How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"?
The code base contains Kotlin and Java as well
Don't let Lunduke Journal see this post, he might have an annurism.