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

391–400 of 430 posts

Re: Rust in Android: move fast and fix things

#391

Post by tialaramex »

almostgotcaught wrote: post #213
tialaramex wrote: post #201

Earlier quoted context omitted.

This idea that if Rust doesn't have all those memory safety bugs it must somehow have loads of other bugs we haven't discovered reminds me of Americans insisting that countries which don't have their lousy gun safety problems must have the same effects by some other means they haven't detected - Like, OK England doesn't have lots of gun murders like America, but surely loads of English people are just dropping dead b…

https://en.wikipedia.org/wiki/No_true_Scotsman

I don't see the connection, did you reply in the wrong place?

Re: Rust in Android: move fast and fix things

#392

Post by WhyNotHugo »

josephg wrote: post #129
WhyNotHugo wrote: post #95

Earlier quoted context omitted.

Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality. Distributing Rust software is the pain that it is mostly because of how Cargo works. It’s pretty much impossible to sanely distribute something that isn’t a headache for downstream to consume.

Can you say more? I’ve found it a joy to use compared to CMake and friends. How does it make it harder to consume something downstream? Seems easy enough to me - just share the source crate. Are you trying to distribute pre compiled code or something like that? I can see how that would be harder - cargo doesn’t really support that use case. How would you improve cargo?

> just share the source crate

That’s a nice concrete example of something that sounds simple but is a nightmare.

Let’s be clear: the goal is to distribute a tarball which the receiver can build. Crates won’t be packaged in the target host (that’s part of Rust’s design), so we don’t have any choice but to include them too.

But there’s no simple way of gathering all of these. “cargo vendor” fetches all transitive dependencies for all platforms. So if any dependency supports windows, you end up with 400MB(!) of windows-only dependencies, even if your project doesn’t target windows. This makes “cargo target” useless.

There’s “cargo-vendor-filtered”, a huge hack around this bug, but it’s also broke in subtle ways.

In the end, if you want to distribute a tarball which a downstream can build, you can’t. Cargo works online only.

Like I said: cargo is too opaque. There’s no command to generate a list of files that it would download for a build. There’s no command to fetch all “real” dependencies. It too opaque an monolithic, doing everything in one indivisible way. This is a great experience for the developer, but awful for anyone else.

Re: Rust in Android: move fast and fix things

#393

Post by ChadNauseam »

kccqzy wrote: post #248
lmm wrote: post #242

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

Are associated types type families? I'm not sure. They seem more similar to functional dependencies to me. But I'm only familiar with type families from Haskell so maybe I'm missing some broader context.

Re: Rust in Android: move fast and fix things

#394

Post by AlotOfReading »

tialaramex wrote: post #390
AlotOfReading wrote: post #372

Earlier quoted context omitted.

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.

C standard N3096, Section 4:

    A conforming program is one that is acceptable to a conforming implementation.
That definition goes all the way back to C89. The C++ standard drops it for the term "well-formed program", but adds enough clarifications in 1.4 to mean essentially the same thing.

Re: Rust in Android: move fast and fix things

#395

Post by wakawaka28 »

mx7zysuj4xew wrote: post #309
wakawaka28 wrote: post #197

Earlier quoted context omitted.

One who has tried the language and hates it can completely dismiss it. Memory issues can be fixed in ways that don't involve rewriting millions of lines of code and the ensuing chaos, feature degradation, retraining, etc. that goes with it.

Your reply isn't necessarily "polite" but your reaction and is entirely appropriate considering the headaches these people are bringing

It's not just the headaches, it's the smugness with which they tell us that C and C++ are too bad to be used and the only solution is to throw it all away and start over. I've seen some smug language evangelists before, but Rust has the worst. It's just too much work to rewrite everything and retrain everyone, for the sake of maybe preventing this one category of error. Calling memory errors "unsafe" is also a bit of a stretch.

Re: Rust in Android: move fast and fix things

#396

Post by josephg »

arw0n wrote: post #377
josephg wrote: post #170

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…

At least the Rust compiler gives pretty good advice on what is going wrong. And for complete beginners, agentic AI can soften the pain a lot if used correctly. By used correctly I mean the following work flow: 1) Design in correspondence with AI. Let it criticise your ideas, give you suggestions on tools/libraries/techniques, and have concepts and syntax explained to you. Stay aware that these models are sycophantic…

> I believe that Rust is the language benefiting the most from agentic AI

Except in my experience, chatgpt and claude both struggle to write rust code that compiles correctly. Chatgpt is pretty good at complex tasks in typescript like "Write a simple snake game using (web framework x). It should have features X and Y". Its can be surprisingly good at some complex problems like that.

If you try the same in rust, it often fails. I've also had plenty of situations where I've had some complex borrowing error in rust code, and chatgpt just can't figure it out. It goes in loops. "Oh I see the problem. Sure, this should fix it ..." except the "fixed code" fails in just the same way.

I'm not sure why. Maybe there's just not enough rust code in the training set for chatgpt to figure it out. But rust is definitely a weakness of the current generation of models.

Re: Rust in Android: move fast and fix things

#397

Post by josephg »

WhyNotHugo wrote: post #392
josephg wrote: post #129

Earlier quoted context omitted.

Can you say more? I’ve found it a joy to use compared to CMake and friends. How does it make it harder to consume something downstream? Seems easy enough to me - just share the source crate. Are you trying to distribute pre compiled code or something like that? I can see how that would be harder - cargo doesn’t really support that use case. How would you improve cargo?

> just share the source crate That’s a nice concrete example of something that sounds simple but is a nightmare. Let’s be clear: the goal is to distribute a tarball which the receiver can build. Crates won’t be packaged in the target host (that’s part of Rust’s design), so we don’t have any choice but to include them too. But there’s no simple way of gathering all of these. “cargo vendor” fetches all transitive depen…

> Let’s be clear: the goal is to distribute a tarball which the receiver can build.

Thanks for clearing that up. What problem does that solve? I've never tried to do that, but I can see how it would be a pain in the neck.

I wonder how hard that would be to fix. It doesn't sound like a difficult feature to implement in cargo. I wonder how amenable the cargo devs would be to adding something like that?

Re: Rust in Android: move fast and fix things

#398

Post by kccqzy »

ChadNauseam wrote: post #393
kccqzy wrote: post #248

Earlier quoted context omitted.

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

Are associated types type families? I'm not sure. They seem more similar to functional dependencies to me. But I'm only familiar with type families from Haskell so maybe I'm missing some broader context.

Yes they are type synonym families. And yes they are quite similar to functional dependencies because it is conceived as an alternative to functional dependencies but it expresses the programmer’s intent more clearly.

Re: Rust in Android: move fast and fix things

#399

Post by LexiMax »

kccqzy wrote: post #385
LexiMax wrote: post #354

Earlier quoted context omitted.

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…

> The C++ language has evolved quickly, with a release every three years or so.

There was a revival of C++ starting with C++11 and ending around the era of C++17. It was, frankly, great. However, a few things happened around and since C++20 that has caused the language to backslide.

First, it seems like corporate support for C++ has dropped significantly. Apple, having successfully replaced GCC with Clang for their own internal use, no longer cares that much about keeping up with the latest C++ features, choosing to prioritize Swift instead. Google seems to have slowed their contributions after being blocked from any commitments that opened up the possibility of breaking ABI. Microsoft has gutted their Visual C++ team, which has significantly slowed the implementation pace of new features and fixing bugs...unless they're related to Unreal Engine. There are also persistent rumors going around that Microsoft are working on their own project in the spirit of rustc-codegen-gcc, but for Visual Studio.

Second, it seems like a lot of the new blood that the revival decade had attracted to the C++ community and standards committee have stopped participating and given up. There's probably not one or two all-encompassing reasons for this, but the disconnected stories I keep hearing about just leave me feeling sad for the future of C++. Anecdotally, the ones that I see that are most commonly cited up are the horrendous rollout of C++ modules, the drama surrounding Safe C++ vs Safety Profiles, and the circling of the wagons around rot13_content_warning("pbaivpgrq puvyq encvfg") Arthur O'Dwyer.

If I had to pick one own-goal in particular that ground my gears from a technical perspective, it's the ordeals of the developer who tried to get `std::embed` into C++. Going through the standardization process was such a nightmare for her - including trying to convince the standards committee that it was a problem worth solving in the first place - that she eventually gave up and took the idea to the C standards committee instead. After a few rounds of back-and-forth feedback, C23 now has #embed. Not only did C get the feature before C++, but the C++ standards committee gave up whatever say they had in the shape of the final product.

That's not to say that I'm not looking forward to certain modern C++ features. Concepts are great, even if they fall well short of the original proposal. I use std::span and std::expected in every project I can, even if I have to use third-party polyfill libraries to deliver them. Modules could be nice when they're more widely supported. But _man_ the future of C++ looks pretty bleak from where I'm sitting, and it seems like the people in a position most able to do something about that future aren't making wise decisions.

Re: Rust in Android: move fast and fix things

#400

Post by jkrejcha »

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…

> No mainstream implementation does that for memory unsafety due to the performance overhead

It depends on what is considered memory safety here (especially when some of them are arguably unforced errors in the standards), but many implementations do in fact have options for this ("no delete null pointer checks" for example is an example of one such option, for example, which is used extensively by the Linux kernel for example).

The performance impact tends to be much more negligible outside of, sometimes contrived, benchmarks, especially when compared to algorithmic efficiencies or the like.

Post reply on HN