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.
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 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).
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.
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)...
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.
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.
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!
It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.”
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.
> 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.
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.
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.
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.
> 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.
This would be great if it weren't such a hasty generalization. A comparative analysis against alternative approaches like continued hardening of the legacy code base would have been better to read through. This suggests there is no middle-ground to be had which we know to be false. And all this while oversimplifying legitimate engineering trade-offs like build system complexity and developer retraining costs.
Relying on Google as a credible institution rather than independent verification results is what can only be described as self-evident truth. This is corporate tech evangelism that only benefits Google.
Why does the article avoid adoption barriers due to Rust's steep learning curve? Why does the author gloss over maturity gaps in the toolchain? Why isn't there feedback included from the maintainers of the critical components like HALs and other drivers?
Rust is older today than the K&R Book on C was when Windows, Linux and NextStep were started. Although C was started earlier, it wasn't widely known about until after said book... Let alone C++
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.
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.
>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.
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)...
I dislike Rust, but I would definitely prefer it over the "Android Studio Java / Kotlin thing", for sure.
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 but maybe you 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
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!
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
[delayed]
You would be severely disappointed.
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.
Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.
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.
I think they're comparing new code in Rust vs new code in C++.
I found it interesting that the rollback rate remained more or less constant despite size differences.
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.
Google rewrote Android's Bluetooth stack in Rust.
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...
Sure, but at a macro level the approach is still to "rewrite" Android subsystems in Rust. Just slowly.
The graphs aren't showing up for me on the site unless I click on them
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.
> 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.
> 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.
[1]: https://github.com/google/wuffs
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.
This would be great if it weren't such a hasty generalization. A comparative analysis against alternative approaches like continued hardening of the legacy code base would have been better to read through. This suggests there is no middle-ground to be had which we know to be false. And all this while oversimplifying legitimate engineering trade-offs like build system complexity and developer retraining costs.
Relying on Google as a credible institution rather than independent verification results is what can only be described as self-evident truth. This is corporate tech evangelism that only benefits Google.
Why does the article avoid adoption barriers due to Rust's steep learning curve? Why does the author gloss over maturity gaps in the toolchain? Why isn't there feedback included from the maintainers of the critical components like HALs and other drivers?
Rust is older today than the K&R Book on C was when Windows, Linux and NextStep were started. Although C was started earlier, it wasn't widely known about until after said book... Let alone C++
They’ve already written about it?
https://security.googleblog.com/2023/09/scaling-rust-adoptio...
https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...
And other posts.