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.

Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.

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.

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.

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.

> 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

The graphs aren't showing up for me on the site unless I click on them

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?

Don't let Lunduke Journal see this post, he might have an annurism.

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.