Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

101–110 of 430 posts

Re: Rust in Android: move fast and fix things

#101

> Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust, making it easier for Chromium engineers to deal with data from the web I find this surprising, isn't Wuffs[1] (also made by Google) an even better fit for this particular use-case? (It has compile-time spatial memory safety, where Rust has compile-time temporal safety but runtime spatial safety, with bound ch…

If you're parsing untrusted data, then some level of runtime checking is unavoidable. And Rust's pretty good at letting you encode "I already checked this and therefore don't need to check it again" into the type system.

Re: Rust in Android: move fast and fix things

#102
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…

That’s my favorite feature. Rust turns runtime errors into compile time errors.

All that fighting with the compiler is just fixing runtime bugs you didn’t realize were there.

Re: Rust in Android: move fast and fix things

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

Absolutely crazy.. I never expected that the difference would be so drastic.

Re: Rust in Android: move fast and fix things

#104
post #68

Earlier quoted context omitted.

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.

As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.…

Oh I totally agree with you.

The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense.

On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.

Re: Rust in Android: move fast and fix things

#105
post #93
post #60

Earlier quoted context omitted.

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

I think we can indeed forget about it.

Re: Rust in Android: move fast and fix things

#106
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…

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.

Re: Rust in Android: move fast and fix things

#107
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 against its adoption for everything.

When you see shit like "[...] should be rewritten in Rust because memory safe", it shows that people have no idea what memory safety even is. There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.

The downsides of Rust is that its ownership semantics are often cumbersome to write, which slows down development. Rust is also still evolving because of the stuff that happens under the hood. And for a lot of things, where network latency is dominant and cpu cycles are spent sleeping waiting for responses to come back, you don't need natively compiled code in lieu of python or node that are way more flexible and faster to develop in.

So in most cases, Rust is not applicable, when you can write perfectly memory safe code faster.

Re: Rust in Android: move fast and fix things

#108

The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say…

I think Rust is easier to learn than C++

Re: Rust in Android: move fast and fix things

#109
post #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! I…

>It's all nonsense,

How is any of that wrong?

Re: Rust in Android: move fast and fix things

#110
post #106
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…

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

Post reply on HN