Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

231–240 of 430 posts

Re: Rust in Android: move fast and fix things

#231

Earlier quoted context omitted.

Google3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing. If I were to go to another company I’d promote using either of the above.

What does Android do for Rust?

It uses Soong which internally calls rustc: https://source.android.com/docs/setup/build/rust/building-ru...

Re: Rust in Android: move fast and fix things

#232
post #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 refr…

[deleted]

Re: Rust in Android: move fast and fix things

#233
post #196

Earlier quoted context omitted.

An earlier Google blog post from the same series (link in the first sentence) pointed out why: new code tend to have more vulnerabilities than established code. So it makes more sense to write new code in Rust than to rewrite old code in Rust. After all new features are still being added and new code needs to be written; it’s not like the codebase is done with features.

According to that blog post ( https://security.googleblog.com/2024/09/eliminating-memory-s... ), the vulnerability density for 5 year old code in Android is 7.4x lower than for new code. If Rust has a 5000 times lower vulnerability density, and if you imagine that 7.4x reduction to repeat itself every 5 years, you would have to "wait" (work on the code) for... about 21 years to get down to the same vulnerability dens…

Remember that there are other types of vulnerabilities too. If there are less of them in old code then it may make up for more memory issues.

Re: Rust in Android: move fast and fix things

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

There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it. And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).

People are worried about half-assed[0] rewrites that break functionality and introduce exciting, new vulnerabilities due to improper implementation. And they aren't wrong to fear that, given the multiple issues we've seen in just the past week with Ubuntu's Rust overhaul.

[0]: Or even whole-assed. Memory (un)safety is only one form of vulnerability.

Re: Rust in Android: move fast and fix things

#235
post #149

Earlier quoted context omitted.

>if your code compiles, it usually runs just fine. This was the same argument for Java, which is memory safe, fairly strict in terms of ownership. The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety. The dividends never get there if you don't ever run into this. >And then there's the fact that the program…

> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety. How does Rust not address use after free?

Not to mention out-of-bounds access, uninitialized memory, invalid type casting, and a ton of insidious sources of undefined behavior

Re: Rust in Android: move fast and fix things

#236

Earlier quoted context omitted.

I don't know much about how it got started. I'm curious how much of Rust's capabilities depend upon recent CS breakthroughs. Could we have made Rust in 1990? The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?

> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware? As I understand it, a lot of the slowness of the rust compiler comes about from llvm. And how rust and llvm interoperate. Rustc creates and sends gigabytes of stuff to llvm - which passes all of that to its optimizer. If you skip all that work - for example by running cargo check - the compiler is an order of mag…

The obvious(?) question is why it sends gigabytes of stuff to llvm and if that can't be reduced somehow.

Re: Rust in Android: move fast and fix things

#237
post #219
post #207

Earlier quoted context omitted.

> It's absolutely possible to bork ownership and have multiple thread trample a struct. This is specifically the one place where go is not memory safe IMO. > It's absolutely possible to compute wrong pointer offsets. In Go? Without the `unsafe` package (at which point you are explicitly opting out)? How? There's no pointer offset in the first place. > It's absolutely possible to dereference nil. Yeah, but that's safe…

Using data races: https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Right, that's the first category, "It's absolutely possible to bork ownership and have multiple thread trample a struct" resulting in undefined behavior.

Re: Rust in Android: move fast and fix things

#238

Earlier quoted context omitted.

The only people I’ve met who seem to think it’s a feud war are a few dyed in the wool C++ fans who implicitly hate the idea of programming anything else. Rust is just a language. It has some strengths and weaknesses just like every programming language. Some of its strengths are incredibly compelling. Personally I’m relieved that we’re starting to see real competition to the C & C++ duopoly. For awhile there all the…

[flagged]

> That is a surprising opinion. Rust marketing is entirely based - like in this submission - on comparing its memory safety to C/C++ and saying that C is bad!

I'm not really sure what you expect here. Like, a large driving factor of using rust (compared to C/C++) is that it has better memory safety. Should rust not talk about that? Should we try and be careful about the feelings of C/C++ devs and not name the truth in the room around memory safety?

The reason android is moving to rust is because it decreases the memory related defect rate compared to C++. Should we shy away from talking about C++ memory bugs because they're somehow embarrassing?

When C came out, I'm sure a lot was written about how much easier it was to program in compared to assembly. Does that mean there's a feud between C and assembly? I'm sure some assembly developers felt under attack. But its not a feud. Just two tools with different use cases. That's how I see C and rust.

Re: Rust in Android: move fast and fix things

#239

Earlier quoted context omitted.

In science, you go out of your way to control for confounding factors. This isn't that.

Having been close to someone who went through the PhD process to a career in research, this is a sadly common but romantic and incorrect view of science as practiced in the world today.

A lot of what folks call science isn't science.

So, I'm not being romantic. I'm being realistic. And I'm happy to call B.S. on a lot of published research, because doing so gives me more predictive power than that research

Re: Rust in Android: move fast and fix things

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

There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it. And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).

>"There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire."

Nah. For me it induces vomit. Any time the vulnerability is mentioned a horde will arrive promptly and sing "rewrite the ... " in Rust.

For fuck's sake. We got it. We know it is mostly memory safe with bunch of other protections baked in. So go and rewrite it and then try to sell it to your customer and have them pay for this job. If you succeed - congrats, good for you and for the "victims". If not - stop nagging people who have other things to worry about.

Post reply on HN