Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

331–340 of 430 posts

Re: Rust in Android: move fast and fix things

#331
post #227

Earlier quoted context omitted.

The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus . C is not simple, it is inept. There are so, so many bargain-bin features and capabilities that it just cannot do that it ends up creating much MORE complex code, not less complex code. I mean, just the pretense tha…

> Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about. And Rust is significantly better at this than C++ for the simple reason that mut is a modifier. I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add…

> I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it

Adding const to _function-local_ variables only really matters when you "leak" a pointer or ref, whether mutable or const, to a function or variable the compiler can't optimize away:

    std::size_t sz = 4096;
    const std::size_t &szRef = sz;
    some_opaque_func(szRef);
    if (sz != 4096) std::abort(); // cannot be optimized away unless sz is const
as there is no way to know if something obtains a mutable ref to sz down the line.

In other cases like RVO, adding const is actually detrimental as it prevents the move-constructor from being selected (likewise with the move assignment operator).

Rust _needs_ to have const by default due to its aliasing model ("only one mutable ref per object") and you can't have cheap bound checks without this. But that, too, is a tradeoff (some classes of programs are hard to code in Rust)

Re: Rust in Android: move fast and fix things

#332
post #159

Earlier quoted context omitted.

Rust is more difficult to learn the basics of than C, but I'm not sure it's more difficult to learn to write memory-safe code in Rust than in C. It's also not clear to me it's that much harder to learn Rust than it is to learn how to write equivalently-high-level code in C++ _unless you end up in one of the areas where Rust is really hard_. But a lot of systems code doesn't end up in those areas. Some does, and then…

How about you teach some of those students to Bootstrap a Linux cross compile both with and without rust then come back and answer this reply again

This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software that meets a particular set of requirements and those requirements include resilience to handling untrusted inputs.

Of course adding an additional set of tooling complicates an environment. I'm sure that was the case for Google in adding Rust to Android as well. And yet - it seems to have proved worth it. And I suspect that in the long term it will prove likewise for Linux, because Linux shares the same requirements and has a similar threat model it needs to guard against.

Re: Rust in Android: move fast and fix things

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

Yeah, I am blown away. Assuming that these stats are true/verifiable, this spells real doom for C++. What is the point of C++ in 2025 except to maintain a large, existing source code base? Else, you should be doing everything that you used to do in C++ in Rust.

> What is the point of C++ in 2025 except to maintain a large, existing source code base?

Half of useful things to do are impossible or plain cumbersome to write in rust given the semantics and constraints of the borrow checker. Try to write self referential structures in rust and you'll have a more nuanced opinion.

Re: Rust in Android: move fast and fix things

#334

Earlier quoted context omitted.

70% of bugs in a large mature c++ code base come from memory safety bugs. Yes it's not the only type of bug, but it sure is the majority. Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful. Rust enums make it easier to associate state with specific states, option types actually force you to check if they are valid, result types force you to check for errors, etc. Any…

> 70% of bugs in a large mature c++ code base come from memory safety bugs. Are 100% of those exploitable? This single ended statistic is simply not useful. > Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful. You have proof of this? > Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits. That's not how these measureme…

> Are 100% of those exploitable? This single ended statistic is simply not useful.

Some more links/statistics (including on 0-days exploited in the wild) here: https://www.memorysafety.org/docs/memory-safety/#how-common-...

> You have proof of this?

One class of non-memory-safety bugs that safe Rust entirely prevents is data races: https://doc.rust-lang.org/nomicon/races.html

> That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.

Are the advantages in those cases (option/result) properly realized when it's just piled on top as something you could do?

I still have to be wary that, for instance, std::strchr could return a nullptr which I might pass on without handling. Plus even with std::optional it's on me to remember to check val.has_value(), else it's undefined behavior to access.

Whereas in Rust, s.find() must return an Option because there's no null for it to return otherwise, and accessing the inner value (`match`, `if let`, ...) requires handling the Option::None case.

> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.

Large compared to C or Zig, but not compared to C++.

Re: Rust in Android: move fast and fix things

#335

Earlier quoted context omitted.

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

If you type correctly at border of your system, then TS will be very close to a formal verification of your code. This won't catch all bugs, but even broad categories for you data is helpful. If you know your input is a non-null string. Then it will warn you of every non string usage. It won't catch whether it's a name or an email, but knowing someone tries to divide it by zero is helpful.

It's a lot more effort, but branded types for conceptual differences can bridge that last gap

Re: Rust in Android: move fast and fix things

#336
post #330

Earlier quoted context omitted.

Sure, building C/C++ code into an .so file kinda works but that's about it, try building the APK entirely with cmake, that's simply not supported, you'll have to integrate with Gradle. The result is a complexity clusterf*ck that's a nightmare to maintain. The NDK team should take a long hard look at Emscripten to get some inspiration how native code development is integrated into a 'native-hostile' runtime platform.

Interesting that you give Emacripten as example, given how badly documented its whole tooling is, and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded, unless using the Github installation from source.

The one great feature of Emscripten is that you can do:

    emcc hello.c -o hello.html
...and it produces an output that's immediately runnable in a web browser instead of just a bare .wasm file which needs to be wrapped in a html with additional steps.

E.g. emcc is a drop-in replacement for gcc/clang which can be used directly in a C/C++ build tool as a C/C++ compiler and linker while still doing the right thing (producing a runnable .html).

The NDK equivalent would be a gcc-compatible compiler wrapper which can do this:

    ndkcc hello.c -o hello.apk
...such a simple and obvious thing to do, yet it doesn't happen because the Android SDK/NDK developers have no clue about developer workflows outside of their precious Java ivory tower.

> and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded,

That's a feature, not a bug. It's trivial to install different emsdk versions side by side, each entirely self-contained and without polluting the system or requiring external dependencies.

The separate Java dependency also has been dropped a while ago, since the only remaining component that depends on Java is the optional Closure compiler step, and that comes now with an embedded Java runtime (as far as I'm aware at least).

Re: Rust in Android: move fast and fix things

#337
post #196

Earlier quoted context omitted.

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

An earlier Google blog post from the same series (link in the first sentence) pointed out why: new code tend to have more vulnerabilities than established code. So it makes more sense to write new code in Rust than to rewrite old code in Rust. After all new features are still being added and new code needs to be written; it’s not like the codebase is done with features.

I also feel like this is good advice when making a language shift, or any _other_ shift, even a stylistic one.

A lot of my coworkers get in this situation where, when a change in direction is made, they feel like we have to stuff the roadmap with work to rewrite everything. That work is... 0 value, in most cases, unless the decision we have made is intended to directly solve an issue in the existing code.

Many times I find that if you just do new work in the new thing, you'll "naturally" prioritize rewriting at the right rate. When we do it that way, we end up replacing, rather than rewriting, those legacy systems, which avoids the pitfall of trying to reproduce prior behavior, down to the bugs it may have had.

Re: Rust in Android: move fast and fix things

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

Yeah, I am blown away. Assuming that these stats are true/verifiable, this spells real doom for C++. What is the point of C++ in 2025 except to maintain a large, existing source code base? Else, you should be doing everything that you used to do in C++ in Rust.

That's also a reason why Google is researching with Carbon, they have for sure a hunger to migrate away from C++.

Re: Rust in Android: move fast and fix things

#339

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

That is an issue with how TS works, but it can be significantly improved upon by using a library to verify the structure of deserialized data. zod is one example, or you could use protobufs. Fundamentally, this is an issue with any programming language. But having your base "struct"-like type be a hashmap leads to more mistakes as it will accept any keys and any values.

I disagree that this is an issue in every language - the problem is that in other languages the validation against some schema is more or less required for unmarshalling, and it's optional in TS.

Seeing a deserialization error immediately clues you in that your borders are not safe. Contrast that with TypeScript, where this kind of issue can lead to an insidious downstream runtime issue that might seem completely unrelated. This second scenario is very rare in other languages.

Re: Rust in Android: move fast and fix things

#340
post #332

Earlier quoted context omitted.

How about you teach some of those students to Bootstrap a Linux cross compile both with and without rust then come back and answer this reply again

This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software that meets a particular set of requirements and those requirements include resilience to handling untrusted inputs. Of course adding an additional set of tooling complicates an environment. I'm sure that was the case for Google in adding Rust to Android as well. And yet - it…

The reason it is relevant is this:

"This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software"

A lot of your argument assumes that you've already have an entire working build environment readily available. If this is not the case, what used to be a fairly straightforward C compile now becomes an massive ordeal

Post reply on HN