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

381–390 of 430 posts

Re: Rust in Android: move fast and fix things

#381

Post by IshKebab »

ActorNightly wrote: post #369
IshKebab wrote: post #139

Earlier quoted context omitted.

Writing the tests before the code only really works if there's an interface that's fully defined and well specified in advance. There are definitely times where that is the case, but in my experience it usually doesn't work like that.

It doesn't work like that because people are afraid to change things up. Lots of time people want to see working code that works for nominal use cases before hand.

No it's because often designing the interface and writing the implementation go hand-in-hand.

Re: Rust in Android: move fast and fix things

#382

Post by ActorNightly »

kibwen wrote: post #167
ActorNightly wrote: post #79

Earlier quoted context omitted.

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.

> That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does. Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is n…

Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem.

The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold.

But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id.

So you simply have a system of tracing where memory gets used.

But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.

Re: Rust in Android: move fast and fix things

#383

Post by danudey »

ActorNightly wrote: post #109
danudey wrote: post #91

Earlier quoted context omitted.

Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C! I…

>It's all nonsense, How is any of that wrong?

It's all correct and also pointless and irrelevant. It all boils down to "Rust doesn't fix every possible problem so why not stick with something that still has every possible problem?"

In other words, they're upset that a new thing isn't popular so they're trying to think of any argument against it, but none of their arguments are relevant. Yes, you can still write bugs in Rust; of course you can. What you can't do is write memory safety bugs in Rust, which are a huge proportion of security bugs that occur. Rust gives you a massive decrease in attack surface automatically.

This is ignoring the ecosystem, which is full of better tooling, better library packaging, better testing, and just in general an overall better language, but instead of trying to argue the language on its merits they're trying to argue that it's not perfect so why bother.

I've also heard the same arguments about C++; 'anything you can do in C++ you can do in C!', which is technically true but ignores the fact that if I want to do something C++ does it usually makes more sense to use C++ to do it rather than e.g. trying to hack the concept of objects, private methods, templates, etc. into C myself.

Re: Rust in Android: move fast and fix things

#384

Post by danudey »

baq wrote: post #268
danudey wrote: post #68

Earlier quoted context omitted.

As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.…

The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills. I don’t see a way around it, programming…

> The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation

Yes, this is the biggest issue with Rust that I've seen; most language will let you do something wrong and then as you learn you get better. Rust will refuse to compile if you're not doing things correctly (and normally I would put 'correctly' in quotes but correctness in Rust is well defined).

The first time I tried to experiment with learning Rust was a disaster. I just wanted to decode some JSON and filter it, but -- oops! -- I don't own that variable. Okay, well I can pass it somewhere else mutably, right? But then that function does the work and returns something that... what's a lifetime? What's a 'a mean? How do I... screw it, I'll go back to Python.

Eventually, after the tooling and the tutorials got better I came back to it and really enjoyed what I've seen so far and even rewrote one of my own personal tools in Rust[1] to experiment with. It's nothing impressive, but it was fun to do.

[1] https://github.com/danudey/rust-downloader

Re: Rust in Android: move fast and fix things

#385

Post by kccqzy »

LexiMax wrote: post #354
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).

In my experience, the loudest critics of Rust I have heard are actually seasoned C and C++ developers who are incredibly good at one or both languages, but know almost nothing outside it. On one hand, C++ is an incredibly complicated language that one can invest considerable amounts of time into. It also used to occupy a unique niche where you get tons of abstraction features yet as much blazing speed as you care to…

> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades

That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable.

Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages in roughly the same space such as Zig or Nim, or occasionally Go. They whine because they think Zig or Nim should take the place of Rust.

Re: Rust in Android: move fast and fix things

#386

Post by danudey »

ActorNightly wrote: post #367
baq wrote: post #270

Earlier quoted context omitted.

It isn’t wrong, it’s misguided. You can write the same code in a Turing machine, too.

Sure, but the discussion against Rust is basically saying that you can have the same features without the downsides of using Rust, which is objectively true. For example, memory analyzers like valgrind work great.

If you assume that the only benefit of using rust is built-in valgrind, sure, but there's more to the language than preventing off-by-one errors.

If people don't want to use the language then that's fine, no problem, but a lot of people do want to use the language because it's just a great language to use as well as having memory safety.

Re: Rust in Android: move fast and fix things

#387

Post by super_flanker »

selfmodruntime wrote: post #39
pizlonator wrote: post #9

This isn't control for confounding factors. For example: folks are more likely to rewrite stuff that is well-understood, and stuff that is well-understood is going to have shorter review times and lower rollback rate. That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more…

This article is mostly about new code.

This, from my limited experience working on AOSP at Google, only the newer code were being written in Rust, not the existing code. But that was 2 years ago.

Re: Rust in Android: move fast and fix things

#388

Post by super_flanker »

ActorNightly wrote: post #79
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.

And tell me how that pointer semantics would do * a very strict type checking * Pattern matching * Algeberic data type

Plenty of people don't write Rust for additional memory safety, they write Rust because the features provided by it is overall very balanced & encourages developer to write code which handles almost all edge cases.

Re: Rust in Android: move fast and fix things

#389

Post by satvikpendem »

echelon wrote: post #142
imron wrote: post #102

Earlier quoted context omitted.

That’s my favorite feature. Rust turns runtime errors into compile time errors. All that fighting with the compiler is just fixing runtime bugs you didn’t realize were there.

Rust is the most defect-free language I have ever used. I'd wager my production Rust code has 100x fewer errors than comparable Javascript, Python, or even Java code. The way Result , Option , match, if let, `?`, and the rest of the error handling and type system operate, it's very difficult to write incorrect code. The language's design objective was to make it hard to write bugs. I'd say it succeeded with flying co…

Now try an actual functional programming language. I like Rust too but those features all come from FP, and FP languages have even more features like that that Rust doesn't yet or can't have.

Re: Rust in Android: move fast and fix things

#390

Post by tialaramex »

AlotOfReading wrote: post #372
tialaramex wrote: post #344

Earlier quoted context omitted.

The C++ ISO document describes conforming implementations of their language, ie compilers and similar tools - that conformance isn't a property of your program at all. So far as I can tell there is no mention of the program conformance you're describing.

There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation. In theory you could have an implementation that gives semantics to UB like Fil-C or CCured do. No mainstream implementation does that for memory unsafety due to the performance overhead, and conforming implementations are required to document those extensions. I don't think there's a sane ar…

> There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation.

Perhaps it "basically" says that, but it certainly doesn't appear to literally say any such thing, so you're going to need to specify where you believe you saw this so that I can have any idea what it actually says.

Post reply on HN