Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

91–100 of 430 posts

Re: Rust in Android: move fast and fix things

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

Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C!

It's all nonsense, but it would be hilarious if it weren't so ignorant.

Re: Rust in Android: move fast and fix things

#92
post #30

Earlier quoted context omitted.

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

Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.

> If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go

I mean, at that point pretty much every language would be a decent choice.

Re: Rust in Android: move fast and fix things

#93
post #60

Earlier quoted context omitted.

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…

Don't forget this list of expectations for SPARK [1] too, if you want even safer, high-integrity, and formally verified code on Android!

[1] https://www.adacore.com/about-spark

Re: Rust in Android: move fast and fix things

#94
post #23

Earlier quoted context omitted.

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

Yeah, there's also a freetype replacement https://github.com/googlefonts/fontations

I think they're trying to avoid rewriting things for no reason though. The things being rewritten tend to have a history of security problems or other issues that would be cause for a rewrite even if it wasn't in Rust.

Re: Rust in Android: move fast and fix things

#95
post #13
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.

Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality.

Distributing Rust software is the pain that it is mostly because of how Cargo works. It’s pretty much impossible to sanely distribute something that isn’t a headache for downstream to consume.

Re: Rust in Android: move fast and fix things

#96
post #74

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 is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.

Re: Rust in Android: move fast and fix things

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

Re: Rust in Android: move fast and fix things

#98
post #30

Earlier quoted context omitted.

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

Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.

> Great multithreading

Until you stumble upon the countless footguns. At least they generally don’t lead to memory unsafety, just garbage data.

Data Race Patterns in Go

https://www.uber.com/blog/data-race-patterns-in-go/

Re: Rust in Android: move fast and fix things

#99

Earlier quoted context omitted.

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

Going out of your way would involve committing unethical experiments, which is absolutely frowned upon by scientists.

And many experiments are simply impossible to do in a manner that completely removed every outside factors. But that doesn't mean that an experiment's results are immediately bad.

Re: Rust in Android: move fast and fix things

#100
post #13

Earlier quoted context omitted.

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.

Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality. Distributing Rust software is the pain that it is mostly because of how Cargo works. It’s pretty much impossible to sanely distribute something that isn’t a headache for downstream to consume.

Can you expand on your reasoning? Because the opposite seems to be true when it comes to projects like uv. People love the single-file executable -- easy to just compile that for a platform and have your users download it. It seems like the uv project is having a good time with that model, so I think they show it's not "impossible". Maybe they're doing something different I'm not aware of? Or maybe your use case is different, so what's impossible about your situation?
Post reply on HN