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

241–250 of 430 posts

Re: Rust in Android: move fast and fix things

#241

Post by surajrmal »

joshuamorton wrote: post #140
ActorNightly wrote: post #88

Earlier quoted context omitted.

The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And…

I will simply say that Google is one of the few places that, to a first approximation, has this. We have our (pretty good) suite of tests. We can run only affected tests. We can them with instrumentation (*SAN), we can run them under various memory and CPU limits, we can run them 1000 times in parallel to deflake. Anyway Google has all of that, and yet still finds this improvement.

Android testing standards aren't necessarily the same as the rest of Google. At least historically it wasn't, I'm sure things have improved.

Re: Rust in Android: move fast and fix things

#242

Post by lmm »

kccqzy wrote: post #198
lmm wrote: post #183

Earlier quoted context omitted.

> Could we have made Rust in 1990? We did, it was called OCaml. If we'd had any sense we'd've rewritten all our systems code in it. But since C had bigger numbers on microbenchmarks, no-one cared.

One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system. So the ans…

> One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system.

I submit that those advanced features are at most a tiny fraction of why projects like OP are seeing benefits from moving to Rust. E.g. I wouldn't be at all surprised if this Rust on Android project isn't using type families at all, or is using them only in an incidental way that could be replaced without significantly compromising the benefits.

Re: Rust in Android: move fast and fix things

#243

Post by samdoesnothing »

Jweb_Guru wrote: post #223
samdoesnothing wrote: post #209

Earlier quoted context omitted.

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,…

I usually am skeptical about a literal thousandfold improvement, yes. And I'm not saying it's impossible, but rather that the data and the way it's presented has inherent biases. Its on the people making grandiose claims to prove them.

Re: Rust in Android: move fast and fix things

#244

Post by MBCook »

criemen wrote: post #182
jsheard wrote: post #134

Earlier quoted context omitted.

It validates the object shape at runtime, much like you can do in Typescript with a library like Zod. The key difference in this case is that Rust makes it scary to not validate data while Typescript will gladly let you YOLO it and blow your legs off, even in strict mode.

Okay I see, that's a nice secure-by-default point, whereas TS is arguably not secure-by-default.

It’s not. And trying to just be a transformation of the source to JS without its own standard library (mostly, some old stuff doesn’t follow this) means it really isn’t possible with just TS alone.

That’s OK with me. I use TS because I like it and hate the total lack of safety in JS. I have to use JS on the web, so TS it is.

If I don’t need it to run on a webpage, I wouldn’t be writing it in TS. I like other languages more overall.

Re: Rust in Android: move fast and fix things

#245

Post by samdoesnothing »

shakow wrote: post #218
samdoesnothing wrote: post #209

Earlier quoted context omitted.

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.

You're sure of a lot of things.

Because I don't blindly accept bad science? It's more like others are sure that this data confirms their biases.

Re: Rust in Android: move fast and fix things

#246

Post by MBCook »

o11c wrote: post #148
ikety wrote: post #106

Earlier quoted context omitted.

I'm interested in what scenarios you don't get this same feeling when writing TS code? I of course agree with Ruby, JS, and Python.

Typescript doesn't even support notions like "unsigned integer". It is not a serious attempt at type-safety; its main claim to fame is "better than raw Javascript" which is not saying much.

If you need to run in a JS environment it’s a hell of a lot. It’s a FANTASTIC improvement.

I wouldn’t use it server side or for a client application that doesn’t run in a web browser. That’s not its place, for me.

But I will 100% reach for it every time if I need to run in a JavaScript environment.

Re: Rust in Android: move fast and fix things

#247

Post by aw1621107 »

hyghjiyhu wrote: post #236
josephg wrote: post #175

Earlier quoted context omitted.

> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware? As I understand it, a lot of the slowness of the rust compiler comes about from llvm. And how rust and llvm interoperate. Rustc creates and sends gigabytes of stuff to llvm - which passes all of that to its optimizer. If you skip all that work - for example by running cargo check - the compiler is an order of mag…

The obvious(?) question is why it sends gigabytes of stuff to llvm and if that can't be reduced somehow.

> 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 implementing optimizations and better IR generation in rustc itself. As for the monomorphization strategy, I thought I remembered reading something about how Rust technically allows for generics to be implemented via non-monomorphization strategies like type erasure/dynamic dispatch, but I can't seem to find that post/article/whatever it was now so I'm not sure I'm not making it up. That being said, there are patterns to reduce the amount of code generated (e.g., generic facade that forwards to a non-generic implementation), but those need to be manually implemented at the moment and I don't think there's significant work towards automating that at the moment.

Re: Rust in Android: move fast and fix things

#248

Post by kccqzy »

lmm wrote: post #242
kccqzy wrote: post #198

Earlier quoted context omitted.

One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system. So the ans…

> One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system. I submit…

Any Rust code longer than ~20 lines uses Rust iterators which use type families. The Iterator trait in Rust has an associated type called Item. This is the innovation here. Classic type classes can only contain functions not types. It was in 2005 that a paper was written to show how having a type inside a type class makes sense, including how it can be type checked (via entailment of type class predicates with type equality), type inferred (by changing the standard HM system to return partial type equality constraints in addition to substitutions).

Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.

Re: Rust in Android: move fast and fix things

#249

Post by estebank »

aw1621107 wrote: post #247
hyghjiyhu wrote: post #236

Earlier quoted context omitted.

The obvious(?) question is why it sends gigabytes of stuff to llvm and if that can't be reduced somehow.

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

Re: Rust in Android: move fast and fix things

#250

Post by stocksinsmocks »

vacuity wrote: post #179
stocksinsmocks wrote: post #61

Earlier quoted context omitted.

I’m a little perplexed why every time something in rust compiles, there’s a blog post about it. I was under the impression Ada, especially when using provers, has been around much longer and is more robust. I just can’t decide if the massive Rust evangelism budget is a red flag or just a curious sociological case study, but I wish I knew the truth.

Rust has the twin features of significant technical merits and a powerful hype machine. In truth, it's neither the devil nor the best thing since sliced bread. It has enough traction that the tooling and developer experience are always improving, and appeals to a wide range of uses. Rust was lucky enough to get noticed when it was decent pre 1.0, which motivated the community to make it excellent at 1.0, and it's bee…

The history is kind of weird. Graydon was ejected out of his own language and then a machine took over. That is really unusual, and I’m not sure there is an analog anywhere.
Post reply on HN