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

181–190 of 430 posts

Re: Rust in Android: move fast and fix things

#181

Post by bgwalter »

habibur wrote: 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.

Further up they refer to Android C/C++ code, not C/C++ in general:

"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code."

Which means they had a pretty poor code base. If they had spent more time on engineering and less time on features that are canceled after 12 months anyway, they could have written better C/C++.

Re: Rust in Android: move fast and fix things

#182

Post by criemen »

jsheard wrote: post #134
criemen wrote: post #128

Earlier quoted context omitted.

I don't know Rust, and I'm genuinely curious: How does it improve over that problem? When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types? TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?

It validates the object shape at runtime, much like you can do in Typescript with a library like Zod. The key difference in this case is that Rust makes it scary to not validate data while Typescript will gladly let you YOLO it and blow your legs off, even in strict mode.

Okay I see, that's a nice secure-by-default point, whereas TS is arguably not secure-by-default.

Re: Rust in Android: move fast and fix things

#183

Post by lmm »

teaearlgraycold wrote: post #125
petcat wrote: post #96

Earlier quoted context omitted.

Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.

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?

> Could we have made Rust in 1990?

We did, it was called OCaml. If we'd had any sense we'd've rewritten all our systems code in it. But since C had bigger numbers on microbenchmarks, no-one cared.

Re: Rust in Android: move fast and fix things

#184

Post by IncreasePosts »

pityJuke wrote: post #120
habibur wrote: 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).

Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that complexity there is extra room for non-memory safety related bugs.

There's probably also 500x more people who know c to a given level then know rust to a given level.

If we have an analyzer that can find memory safety bugs in C, we could also just put that in the CI pipeline, or as a pre-submit hook before you're allowed to add code to a code base.

Re: Rust in Android: move fast and fix things

#185

Post by crote »

WhyNotHugo wrote: post #95
beeflet wrote: 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.

That sounds a lot like the issues some Linux distros are running into, where they expect to be able to ship one single blessed pre-compiled version of every library, and have each app load it dynamically at runtime.

But that's just not how Rust works: it's trying to fit a square peg in a round hole, and it isn't Cargo's fault that you have trouble with it.

Re: Rust in Android: move fast and fix things

#186

Post by tuetuopay »

WhyNotHugo wrote: post #95
beeflet wrote: 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.

Uuuh how so?

Cargo is a blessing for any source-available project. All bundled up, a `cargo build` away. Because don't you dare say CMake or autotools are better, that's just the stockholm syndrome kicking in because you're familiar with it.

Seriously, how a CMakeLists.txt can even be compared to a Cargo.toml file? One is imperative full of arcane conditions everywhere filled with boilerplate, while Cargo.toml is a declarative manifest of the package?

Though there is one very sore point when distributing software, and that is for distribution package maintainers, because the whole ecosystem has been built around the C model and dynamic linking. That is not even the fault of cargo, since Rust's ABI is not stable thus dynamic linking would not work most of the time. Another thorn is generic stuff, which needs to be monomorphized, and as such don't work with dynamic linking (without Box); C++ actually has the same issue and is why there are so many "header only" libraries for it.

Re: Rust in Android: move fast and fix things

#187

Post by AlotOfReading »

tonyhart7 wrote: post #174
IshKebab wrote: post #143

Earlier quoted context omitted.

1. You don't know what you're doing - everyone makes mistakes. 2. You can still write bugs in Rust but the point is you are far less likely to.

Yeah but 1000x less mistake ????? I mean these people behind android project is atleast one of the better engineer but jesus christ if they can improve so much then I dont know how much average joe can benefit from that

It's not 1000x fewer mistakes overall, it's 1000x fewer mistakes of this one specific family that Rust is designed to eliminate.

They've also seen improvements in developer confidence and onboarding time, but not to the same degree.

Re: Rust in Android: move fast and fix things

#188

Post by EE84M3i »

regular_trash wrote: post #110
ikety wrote: post #106

Earlier quoted context omitted.

I'm interested in what scenarios you don't get this same feeling when writing TS code? I of course agree with Ruby, JS, and Python.

Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data. Also, many built in functions do not have sufficient typesafey like Object.entries() for instance

What do you mean by "safe" in this context?

Re: Rust in Android: move fast and fix things

#189

Post by skydhash »

ikety wrote: post #124
josephg wrote: post #114

Earlier quoted context omitted.

One big source of bugs in TS is structural sharing. Like, imagine you have some complex object that needs to be accessed from multiple places. The obvious, high performance way to share that object is to just pass around references wherever you need them. But this is dangerous. It’s easy to later forget that the object is shared, and mutate it in one place without considering the implications for other parts of your…

Appreciate it, that makes a lot of sense. I feel like I've been trained to favor immutability so much in every language that I sometimes forget about these things.

Similar. I mostly design my code around something like pipe and lifetime. The longer something needs to live the closer it is to the start of the program. If I need to mutate it, I take care that the actual mutation happens in one place, so I can differentiate between read and write access. For anything else, I clone and I update. It may not be efficient and you need to track memory usage, but logic is way far simple.

Re: Rust in Android: move fast and fix things

#190

Post by bgwalter »

josephg wrote: post #154
gchamonlive wrote: post #6

Earlier quoted context omitted.

I personally have zero interest in these feud wars. I'm only glad there are more quality options for Devs to develop safer system tools.

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]
Post reply on HN