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

111–120 of 430 posts

Re: Rust in Android: move fast and fix things

#111

Post by mkehrt »

guywithahat wrote: post #89
mk89 wrote: 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 error handling

Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function.

On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's type.

Re: Rust in Android: move fast and fix things

#112

Post by ikety »

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'm not sure that nobody thinks of this. We just have a finite amount of time. Usually with a solid approach, you get solid performance. Fixing a performance related bug rarely when it comes up, is still a time savings over designing this kind of rigorous process from scratch, and getting everyone on board with it.

Getting rid of a whole host of bugs due to the compiler is a big deal because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. If you can solve this seamlessly I think that's an interesting product that others would be very interested in.

Re: Rust in Android: move fast and fix things

#113

Post by vjerancrnjak »

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

The worst offender is toString which has different types between objects and is everywhere by default.

Re: Rust in Android: move fast and fix things

#114

Post by josephg »

ikety wrote: post #106
iagooar wrote: 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.

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

I’ve made this mistake in TS more times than I’d like to admit. It gives rise to some bugs that are very tricky to track down. The obvious ways to avoid this bug are by making everything deeply immutable. Or by cloning instead of sharing. Both of these options aren’t well supported by the language. And they can both be very expensive from a performance pov. I don’t want to pay that cost when it’s not necessary.

Typescript is pretty good. But it’s very normal for a TS program to type check but still contain bugs. In my experience, far fewer bugs slip past the rust compiler.

Re: Rust in Android: move fast and fix things

#115

Post by iknowstuff »

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.

lol. this take is hilarious in the face of the article you are commenting on. holy cognitive dissonance.

> The downsides of Rust is that its ownership semantics are often cumbersome to write

skill issue

Re: Rust in Android: move fast and fix things

#116

Post by belval »

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.

Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.

Re: Rust in Android: move fast and fix things

#117

Post by krukah »

tick_tock_tick wrote: post #14
mk89 wrote: 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.

I mean we know for sure Rust is unsafe there is whole bug tracker dedicated to all the ways it's unsafe. My favorite is that you can cast any lifetime to static no matter how short it actually is in 100% safe Rust. (doesn't mean it's not an improvement on C++)

I think referencing the well-known cases in cve-rs[1] is quite a bad faith effort. Of course if you try reeeally hard to write unsound code, you can write unsound code. An edge case in the type system downstream of lifetime variance rules is simply not something that matters in any practical attempt to write safe software. I find the tracker interesting since it probes the boundary of the compiler, but it says absolute nothing to the effect of "Rust is unsafe".

[1] https://github.com/Speykious/cve-rs

Re: Rust in Android: move fast and fix things

#118

Post by ModernMech »

duped wrote: post #108
ModernMech wrote: post #80

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

I agree with you as long as you don't know C++ first. I actually teach C++ and Rust to students who only know Java, and they have a much easier time picking up Rust. It's the people who approach Rust with C++ idioms who have the wort time with it. It comes down to the tooling, especially Cargo being the one-stop-shop for everything Rust. Another poster here laments that Cargo is too overloaded with disjoint functionality, but that's actually a benefit for a lot of learners.

Re: Rust in Android: move fast and fix things

#119

Post by darknavi »

belval wrote: post #116
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.

Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.

It's not _that_ hard to believe if you start spraying smart pointers everywhere.

Re: Rust in Android: move fast and fix things

#120

Post by pityJuke »

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

Post reply on HN