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.
Key take.
- Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore.
Of course, I am exaggerating a bit - and I am not even that experienced with Rust.
But after coding with Ruby, JS/TS and Python - it feels refreshing to know that as long as your code compiles, it probably is 80-90% there.
And it is fast, too.
- 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.
by ModernMech
3 subcomments
- 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.
- 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.
by pizlonator
5 subcomments
- 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.
by littlestymaar
2 subcomments
- > 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 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.
by delusional
4 subcomments
- 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.
by mainecoder
0 subcomment
- My friend told me he likes writing rust because he loves doing things that have already been done his senior pushed management to rewrite in rust and got approved after 2 months, he jokingly told him I guaranteed us a job for the next 3 years rewriting will take time. One paycheck collection strategy push Rust -> get adoption -> rewrite code (now memory safe yay) -> collect paycheck rewriting . In the meantime others will write memory unsafe code for you which is new and provide you a paycheck guarantee and the rust compiler helps you take your time when rewriting you can read the old code while it compiles.
by HackerThemAll
0 subcomment
- I hope that Google and/or Rust community can use the 4% of unsafe Rust code in Android to design new Rust functionalities that will help replace some/most/all of them with something safe. Linux would perhaps benefit from that, too.
by spprashant
0 subcomment
- This was a great breakdown. Loved the different aspects they captured beyond memory safety, including the skill improvements within the team as they grew comfortable.
- It'll be interesting down the road to see how this affects the rate of security bugs that are not memory safety related.
- I thought this article was about using Rust for mobile development, like Tauri on Android.
- The graphs aren't showing up for me on the site unless I click on them
- now ahow me how rust
can protect us against
tech giants doing
sauron moves on
our software ecosystems?
- [dead]
by tonetheman
0 subcomment
- [dead]
- Don't let Lunduke Journal see this post, he might have an annurism.
by RustSupremacist
2 subcomments
- 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?
Hacker News