Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

Post reply on HN
Print view View original

21–30 of 430 posts

Re: Rust in Android: move fast and fix things

#21

Post by nixpulvis »

bla3 wrote: post #11
masklinn wrote: post #3

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.

Re: Rust in Android: move fast and fix things

#22

Post by [deleted] »

pizlonator wrote: post #9

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…

[deleted]

Re: Rust in Android: move fast and fix things

#23

Post by gpm »

vbarrielle wrote: post #20
petcat wrote: post #7

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...

Re: Rust in Android: move fast and fix things

#24

Post by VWWHFSfQ »

vbarrielle wrote: post #20
petcat wrote: post #7

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.

Sure, but at a macro level the approach is still to "rewrite" Android subsystems in Rust. Just slowly.

Re: Rust in Android: move fast and fix things

#25

Post by ViewTrick1002 »

tick_tock_tick wrote: post #14
mk89 wrote: post #2

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.

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++)

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...

Re: Rust in Android: move fast and fix things

#26

Post by johnisgood »

beeflet wrote: post #13
mk89 wrote: post #2

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 dislike Rust, but I would definitely prefer it over the "Android Studio Java / Kotlin thing", for sure.

Re: Rust in Android: move fast and fix things

#27

Post by nicoburns »

bla3 wrote: post #11
masklinn wrote: post #3

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.

I think they're comparing new code in Rust vs new code in C++.

Re: Rust in Android: move fast and fix things

#30

Post by mk89 »

beeflet wrote: post #13
mk89 wrote: post #2

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 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)...

Post reply on HN