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

121–130 of 430 posts

Re: Rust in Android: move fast and fix things

#121

Post by ikety »

mkehrt wrote: post #111
guywithahat wrote: post #89

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.

> great error handling Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function. On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's t…

Yep Rust approach won. Pretty much every new language is adopting Result style errors and it's been adapted to plenty of existing languages.

It's a product of functional programming, and for me I can't see how you would ever want to handle errors outside of the functional programming railway-oriented style. For me it's just superior.

Re: Rust in Android: move fast and fix things

#122

Post by quantummagic »

ModernMech wrote: post #100
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 expand on your reasoning? Because the opposite seems to be true when it comes to projects like uv. People love the single-file executable -- easy to just compile that for a platform and have your users download it. It seems like the uv project is having a good time with that model, so I think they show it's not "impossible". Maybe they're doing something different I'm not aware of? Or maybe your use case is d…

Isn't it also the npm model?

Re: Rust in Android: move fast and fix things

#123

Post by teaearlgraycold »

regular_trash wrote: post #110
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.

Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data. Also, many built in functions do not have sufficient typesafey like Object.entries() for instance

That is an issue with how TS works, but it can be significantly improved upon by using a library to verify the structure of deserialized data. zod is one example, or you could use protobufs. Fundamentally, this is an issue with any programming language. But having your base "struct"-like type be a hashmap leads to more mistakes as it will accept any keys and any values.

Re: Rust in Android: move fast and fix things

#124

Post by ikety »

josephg wrote: post #114
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.

One big source of bugs in TS is structural sharing. Like, imagine you have some complex object that needs to be accessed from multiple places. The obvious, high performance way to share that object is to just pass around references wherever you need them. But this is dangerous. It’s easy to later forget that the object is shared, and mutate it in one place without considering the implications for other parts of your…

Appreciate it, that makes a lot of sense. I feel like I've been trained to favor immutability so much in every language that I sometimes forget about these things.

Re: Rust in Android: move fast and fix things

#125

Post by teaearlgraycold »

petcat wrote: post #96
habibur wrote: post #74

5 million Rust LOC One potential memory safety vulnerability found Rust is 0.2 vuln per 1 MLOC. Compared to C and C++ : 1,000 memory safety vulnerabilities per MLOC. Key take.

Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.

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?

Re: Rust in Android: move fast and fix things

#126

Post by ActorNightly »

ModernMech wrote: post #80

The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say…

>if your code compiles, it usually runs just fine.

This was the same argument for Java, which is memory safe, fairly strict in terms of ownership.

The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.

The dividends never get there if you don't ever run into this.

>And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!"

This is a vibe at best. The speed difference is surely there. But it makes very little difference when there are much slower things in the entire workflow, like pulling things from the internet.

Basically, Rust is a good choice for a small subset of things. Android happens to be one of them, because a) you need native code performance, b) you have multiple teams working on many services and c) you have a somewhat closed ecosystem where you control a lot of the low level things. Because of all of this, double frees are a real threat and can pop up as you are passing data around without strict checks.

Re: Rust in Android: move fast and fix things

#127

Post by [deleted] »

pjmlp wrote: post #5

Note that Google still doesn't have official support for using Rust in Android userspace, though. Despite all pluses on the blog, NDK only supports C and C++ tooling, same on Android Studio, and it is up to the community to do the needful work, if anyone feels like using Rust instead.

[deleted]

Re: Rust in Android: move fast and fix things

#128

Post by criemen »

regular_trash wrote: post #110
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.

Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data. Also, many built in functions do not have sufficient typesafey like Object.entries() for instance

I don't know Rust, and I'm genuinely curious: How does it improve over that problem?

When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types?

TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?

Re: Rust in Android: move fast and fix things

#129

Post by josephg »

WhyNotHugo wrote: post #95
beeflet wrote: post #13

Earlier quoted context omitted.

rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.

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?

Re: Rust in Android: move fast and fix things

#130

Post by marcosdumay »

danudey wrote: post #68
nixpulvis wrote: post #21

Earlier quoted context omitted.

Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.

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

Oh, the more junior the developers, the quicker they will get any benefit. That's common for any language that enforces correctness, but the C++ vs. Rust comparison isn't even fair; C++ is an incredibly hard language to use.

Now, if they actually "see" it is another matter.

Post reply on HN