Rust in Android: move fast and fix things • Hacker News Board

Re: Rust in Android: move fast and fix things

#71

Post by ncruces » Thu, Nov 13, 2025, 9:51 PM UTC

gpm wrote: post #17

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.

> I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.

Android uses Soong: https://source.android.com/docs/setup/build

Proprietary code uses the internal version of Bazel: https://bazel.build/

Re: Rust in Android: move fast and fix things

#72

Post by MBCook » Thu, Nov 13, 2025, 9:52 PM UTC

masklinn wrote: post #3

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

We all knew rust was safer. It was the 1000x number that surprised me.

Which is more that rust isn’t that safe in my mind, it’s that bugs are that prevalent. I never would have guessed that.

That 4x rate is very impressive too.

Great seeing all this data from a large big complicated codebase.

Re: Rust in Android: move fast and fix things

#73

Post by MBCook » Thu, Nov 13, 2025, 9:54 PM UTC

mk89 wrote: post #30

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.

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

I don’t disagree, that’s part of why I like Swift so much. Rust looks very C++ to me.

But if I was working in C++ and had a choice of C++ or Rust, I’d go Rust based on this.

Re: Rust in Android: move fast and fix things

#74

Post by habibur » Thu, Nov 13, 2025, 9:56 PM UTC

    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.

Re: Rust in Android: move fast and fix things

#75

Post by manmal » Thu, Nov 13, 2025, 9:56 PM UTC

kridsdale1 wrote: post #55

nixpulvis wrote: post #21

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.

I’d say the same applies for Swift vs ObjC. Let’s end the C era.

Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever.

Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default!

Re: Rust in Android: move fast and fix things

#76

Post by mk89 » Thu, Nov 13, 2025, 9:58 PM UTC

MBCook wrote: post #73

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

I don’t disagree, that’s part of why I like Swift so much. Rust looks very C++ to me. But if I was working in C++ and had a choice of C++ or Rust, I’d go Rust based on this.

Agree! Swift I forgot to mention. What a nice and elegant language.

Re: Rust in Android: move fast and fix things

#77

Post by dwattttt » Thu, Nov 13, 2025, 9:58 PM UTC

pizlonator wrote: post #58

dwattttt wrote: post #47

Earlier quoted context omitted.

> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion. Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?

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.

Re: Rust in Android: move fast and fix things

#78

Post by claudiug » Thu, Nov 13, 2025, 9:59 PM UTC

mk89 wrote: post #30

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.

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

in the beginning I also hate it, but now is fine.

Re: Rust in Android: move fast and fix things

#79

Post by ActorNightly » Thu, Nov 13, 2025, 10:01 PM UTC

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.

Id like to see dev time in Rust vs C++, but generally, I sort of agree. If you use modern C++ with all its features, Rust is generally a better alternative.

That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.

Re: Rust in Android: move fast and fix things

#80

Post by ModernMech » Thu, Nov 13, 2025, 10:02 PM UTC

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 "Rust is too hard!" and they give up.

But if you stick it out, as Google has, the dividend is that more often than with other languages, you are not paying these costs continually but instead reaping dividends on the long run.

First of all, Rust has the Haskell-like property that (as long as the logic is sound) if your code compiles, it usually runs just fine. This is why testing speeds up, because all of the edge cases that are explored during testing were already accounted for by the compiler.

It also translates into easier refactoring, where you can make sweeping changes in the codebase and feel confident that you can put it all back together again.

And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!". Fast is a feature, and your users benefit from it every time they run your code.

It's hard to find that nexus of features in other languages. Usually they are just as fast and hard to write as Rust, without the safety guarantees. Or they are just as safe as Rust, but without the speed. And that's why Rust has hit a sweet spot where other languages can't quite get it.