Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

311–320 of 430 posts

Re: Rust in Android: move fast and fix things

#311

Earlier quoted context omitted.

> The obvious(?) question is why it sends gigabytes of stuff to llvm IIRC it's a combination of technical debt from earlier in Rust's life (it's easier to generate naive LLVM IR and let LLVM's optimizer do the heavy lifting of chewing through that) and how Rust implements generics via monomorphization > and if that can't be reduced somehow. I believe the technical debt bit can be (and is being!) reduced by implementi…

For the latter, the term you want to search for is polymorphization. It is about making the compiler do the work that those manual façades do, automatically.

Yeah, that looks familiar. Thanks for the pointer!

Re: Rust in Android: move fast and fix things

#312
post #302

Earlier quoted context omitted.

Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.

That argument can be applied to unsafe Rust as well. There are code reviews, coding standards and other checks for a reason. Though, I suppose something like C++ profiles, just for modernization, might make it much easier to enforce and track that modern C++ is used.

The difference is that with Rust one can prevent unsafe in the compiler build settings.

Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language.

With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.

Re: Rust in Android: move fast and fix things

#313
post #278

Earlier quoted context omitted.

My favorite framing for this is that rust front loads all the pain. C and C++ are incredibly subtle languages. But you can get a lot of code written before you run into certain foot guns in C and C++. This gives those language a more enjoyable on-ramp for beginners. In comparison, rust is a wall. The compiler just won’t compile your code at all if you do anything wrong. This makes the act of learning rust much more p…

The pain will always remain when refactoring or changing code, with modifications cascading in the function and type definitions. If a language is hard to write at first, it’s always hard to write. The saving grace of C++ is that one mustn’t use the overcomplicated functional aspects, template meta-programming, etc. Through some amazing circumstances, all of the above (or their equivalents) + async is exactly what id…

> If a language is hard to write at first, it’s always hard to write.

That seems obviously false. Most fancy programming languages are difficult to write at first, C++ included. But they all get easier over time.

Rust got way easier to write over time for me. I'm soooo much more productive in it now compared to when I started. Does C++ not get easier to write over time too?

Re: Rust in Android: move fast and fix things

#314
post #169

Earlier quoted context omitted.

I think that it would be foolish for any software engineer to completely dismiss any technology. There is a time and place for any tool, and it is a job of a competent engineer to determine what the appropriate combination of these is that would solve a certain problem within specific constraints. That said, memory safety is one criterion out of many that could be used to make that decision. For a large number of sof…

I dont so much dismiss the technology as the people who insist on rewriting everything in rust. Rust seems to attract a certain mindset of mediocre programmers who yell "security" to shove their poorly written slower code down our throats. Most of them seem to be former web developers who bring all their npm drama to stable C foundations

Stable where?

We're in C23 nowadays, and in Linux distributions there are plenty of npm like drama, one apt/dnf install away with pkg-config, or vcpkg/conan for the more modern folks.

Although I imagine there are a few still stuck in ./configure land.

Re: Rust in Android: move fast and fix things

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

Nope, Rust compiler depends on LLVM and GCC (ongoing), both written in C++.

Then there are enough industry standards that are defined for C and C++, where Rust isn't even visible.

Re: Rust in Android: move fast and fix things

#316

Earlier quoted context omitted.

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.

Zig in spirit is essentially Go without GC. If GC is not reasonable for your usecase Zig seems like an awesome choice. Unfortunately it's probably about 5 to 10 years out from being stable enough for most people being able to write serious applications in it though (notable exceptions being Bun and Ghostty, but they have solid effort behind them keeping them up to date with Zig).

More like Modula-2 in C clothing, given the safety guarantees.

Re: Rust in Android: move fast and fix things

#317
post #207

Earlier quoted context omitted.

How is Go memory safe? Memory safety does not mean "leaking memory". It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way. I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bound…

> It's absolutely possible to bork ownership and have multiple thread trample a struct. This is specifically the one place where go is not memory safe IMO. > It's absolutely possible to compute wrong pointer offsets. In Go? Without the `unsafe` package (at which point you are explicitly opting out)? How? There's no pointer offset in the first place. > It's absolutely possible to dereference nil. Yeah, but that's safe…

My Go is a bit rusty (pun intended), so I may have misremembered, especially with the pointer offsets. (just googled it, I did remember it, sorry for the confusion).

>> It's absolutely possible to reinterpret memory the wrong way. > Again, without the unsafe package? How?

Again my go is rusty, but I saw quite a bit of shenanigans in go with pointer casting from what's essentially a collection of void*. However perhaps those casts blow up at runtime? I'm too used to rust where it's explicit where it'll blow up.

>> It's absolutely possible to dereference nil. > Yeah, but that's safe defined behavior in go equivalent to "unwrap"ing a None option in rust. It reliably crashes. It's not like C where it's undefined behavior and you might crash of you might just corrupt random memory or have the optimizer make your code do something even stranger.

Agreed. I conflated "safety" and "robustness" here. The existence of nil is a thorn in the language.

Thanks for the corrections!

Re: Rust in Android: move fast and fix things

#318
post #220

Earlier quoted context omitted.

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…

> Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.

I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response.

> The Rust literature is poorly written compared to C and Ada

I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing?

I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library:

https://doc.rust-lang.org/std/iter/trait.Iterator.html

Every function in that interface is well documented, with examples.

Here's the equivalent for C++:

https://en.cppreference.com/w/cpp/iterator/iterator.html

Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far.

So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:

http://www.lmdb.tech/doc/group__mdb.html

In rust, any published crate automatically has a docs.rs/cratename link. Eg for serde's reference manual:

https://docs.rs/serde/

And then for the "guide" style explanation they wrote a book:

https://serde.rs/

Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.

Re: Rust in Android: move fast and fix things

#319
post #204

Earlier quoted context omitted.

How is Go memory safe? Memory safety does not mean "leaking memory". It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way. I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bound…

Rust doesn't consider leaking memory to be unsafe.

I mentioned it because I often hear people (not in this thread though) that thanks to its GC preventing memory leaks, Go is memory safe. The GC's role in memory safety is preventing dangling pointers though.

Re: Rust in Android: move fast and fix things

#320

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. I’m sorry if this comes across as dismissive, but I find it hard to take people seriously with complaints about syntax like this. Learning new syntax is really easy. Like, if you’re familiar with C & Go, you could probably learn all the syntax of rust in under an hour. The only surprising part of rust’s syntax is all th…

It's not about learning syntax, it's about finding it generally tolerable to read. I personally find Rust syntax repulsive and would opt for a different language unless Rust was literally the only option. Thankfully it's never the only option, now or in the future.

Can you give some examples? Its hard to agree or disagree if you're not going to make any substantive claims.
Post reply on HN