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

221–230 of 430 posts

Re: Rust in Android: move fast and fix things

#221

Post by Jweb_Guru »

petcat wrote: post #132
teaearlgraycold wrote: post #125

Earlier quoted context omitted.

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.

It wasn't really possible. We had neither the PL techniques nor the computational power to make something like Rust work at the time. All the answers people are throwing around showing it would have been possible rely on a garbage collector and require a runtime, or have many other unacceptable compromises (e.g. no use after free because you aren't allowed to free).

Re: Rust in Android: move fast and fix things

#223

Post by Jweb_Guru »

samdoesnothing wrote: post #209
kibwen wrote: post #163

Earlier quoted context omitted.

Rather, they found one memory safety bug in their Rust codebase, and measured it against the legions of memory safety bugs they found in their C++ codebase. In neither case are they measuring against bugs not found, so no, it's not biased.

Except it's not an apples-to-apples comparison. The C++ code has been around a lot longer, and a lot of it was written with older versions of C++ which didn't have modern safety features. I'm sure there is a bunch of new/delete in their codebase still. And I'm sure they're actively looking for memory safety issues in C++, and probably not so hard (if at all) with Rust.

Is it a usual thing you do that when you're given data about a literal thousandfold improvement, in a context where there are well-understood theoretical and practical reasons why you might have expected to see such an improvement, you make up reasons why it is actually not an improvement at all, without either investigating to see whether those reasons are actually true or demonstrating that even if they were true, they could possibly explain more than a tiny fraction of the improvement?

Re: Rust in Android: move fast and fix things

#224

Post by bgwalter »

Inityx wrote: post #220
bgwalter wrote: post #190

Earlier quoted context omitted.

[flagged]

I don't think materially contrasting yourself with your direct competition quite constitutes a "feud war"

The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.

The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible.

Which is a pity, because the language itself does not seem to be so bad.

Re: Rust in Android: move fast and fix things

#225

Post by cogman10 »

flohofwoe wrote: post #67
pjmlp wrote: 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…

The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.

I'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated.

[1] https://github.com/android/ndk-samples/tree/main/endless-tun...

Re: Rust in Android: move fast and fix things

#226

Post by quotemstr »

flohofwoe wrote: post #67
pjmlp wrote: 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…

The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.

Huh? "Barely"? What are you talking about? The NDK supports compiling C++ just fine. There are CMake files, among other things, ready to use --- as well as Soong native configurations. CMake is under active development. Other toolkits are within easy reach: for example, Meson works fine. Also Bazel. Hell, even autotools can be made to work.

Re: Rust in Android: move fast and fix things

#227

Post by pdpi »

array_key_first wrote: post #208
IncreasePosts wrote: post #184

Earlier quoted context omitted.

Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that…

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 it, and, as readers, we’re left wondering whether things actually need to be mutable, or the author forgot/didn’t know to add const-ness to their code. With Rust having opt-in mutability, you know for a fact that mutability was a deliberate choice (even if sometimes the only motivation was “make the compiler happy”).

Re: Rust in Android: move fast and fix things

#228

Post by bgwalter »

AlotOfReading wrote: post #191
IncreasePosts wrote: post #184

Earlier quoted context omitted.

Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that…

You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all . That's just a basic requirement of what it means to write in those languages. The graph about reverted code also addresses the "illegible bugs" argument. As for an analyzer, that's what ASAN is. I hope I don't need to explain why that's not a universal solution (even tho…

> You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all.

The post you reply to does not indicate a misunderstanding of memory safety at all. .

Re: Rust in Android: move fast and fix things

#229

Post by surajrmal »

themafia wrote: post #216
pityJuke wrote: post #120

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

It's one class of bugs. This is not enough information to make a technical decision. Logic bugs still exist. It's not clear if these are easier or harder to create in Rust. There is some existing evidence to suggest that object oriented programs make it easier to create logical errors and emergent bugs. So, that's why I completely dismiss it, it fraudulently attempts to champion Rust as an obvious replacement of anyt…

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. Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits.

Re: Rust in Android: move fast and fix things

#230

Post by bschwindHN »

mycocola wrote: post #65

I use rust for gamedev (not bevy). I'm unlikely to consider anything else exactly because of stability and throughput.

Always curious to hear from people doing Rust gamedev without bevy! What are the main crates you're using, and what sort of game object architecture are you going with?

I do hobbyist level gamedev in my spare time and found bevy to be a bit too much for the things I want to do.

Post reply on HN