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

131–140 of 430 posts

Re: Rust in Android: move fast and fix things

#131

Post by hardwaresofton »

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.

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

"Absolutely awful" strikes me as wild hyperbole -- you also meant it this way as well, right? What toolchains are not absolutely awful in your mind?

Cargo isn't perfect by any stretch of the imagination -- there are a few common complaints that people have and a bunch of sharp edges (most of which have a github issue that has been open for years), but... "absolutely awful" has to be hyperbole.

Re: Rust in Android: move fast and fix things

#132

Post by petcat »

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?

I think the answer is probably that Rust was possible in the 1980s and 1990s, but such a thing just wasn't practical.

Rust is notoriously compiler-intensive. That wouldn't have been tolerated in the early PC era. When you needed fast compilers that "worked on my machine" and should work on yours. Ship it.

Re: Rust in Android: move fast and fix things

#133

Post by bluGill »

danudey wrote: post #63
bluGill wrote: post #51

Earlier quoted context omitted.

You seem to forget about autotools. Cmake is ugly but I'll take it over autotools.

As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful. At least it knows how to use ninja though.

Problem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.

Re: Rust in Android: move fast and fix things

#134

Post by jsheard »

criemen wrote: post #128
regular_trash wrote: post #110

Earlier quoted context omitted.

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

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.

Re: Rust in Android: move fast and fix things

#135

Post by AlotOfReading »

ActorNightly wrote: post #107
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.

Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper. That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing…

    There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
This is effectively true in C and C++ though. Show me a nontrivial project in either of those languages that has never had a memory safety issue and I'll show you a project that doesn't look at quality. Even SQlite doesn't meet this bar, despite incredibly skilled programmers and an obsessive commitment to quality.

Re: Rust in Android: move fast and fix things

#136

Post by whyever »

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.

Note that N=1 for the memory safety vulnerabilities they had with Rust, so the error of the estimated average number of vulnerabilities per LOC is quite large.

Re: Rust in Android: move fast and fix things

#137

Post by ls-a »

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

[flagged]

Re: Rust in Android: move fast and fix things

#138

Post by marcosdumay »

ActorNightly wrote: post #109
danudey wrote: post #91

Earlier quoted context omitted.

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! I…

>It's all nonsense, How is any of that wrong?

On the sense that you can write a Rust compiler in C and use it to program your software in a better language, yes, all of that is correct.

Re: Rust in Android: move fast and fix things

#139

Post by IshKebab »

ActorNightly wrote: post #88
masklinn wrote: post #3

Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.

The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And…

Writing the tests before the code only really works if there's an interface that's fully defined and well specified in advance. There are definitely times where that is the case, but in my experience it usually doesn't work like that.

Re: Rust in Android: move fast and fix things

#140

Post by joshuamorton »

ActorNightly wrote: post #88
masklinn wrote: post #3

Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.

The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And…

I will simply say that Google is one of the few places that, to a first approximation, has this. We have our (pretty good) suite of tests. We can run only affected tests. We can them with instrumentation (*SAN), we can run them under various memory and CPU limits, we can run them 1000 times in parallel to deflake.

Anyway Google has all of that, and yet still finds this improvement.

Post reply on HN