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

31–40 of 430 posts

Re: Rust in Android: move fast and fix things

#31

Post by pizlonator »

gpm wrote: post #15
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…

The first chart does in fact a compelling reason to believe the effect is not that at all. If the "easy" code was predominantly being rewritten you would expect to % new memory unsafe code and % memory safety vulnerabilities to scale at different rates as the difficult to work on areas remained in C and kept causing new memory vulnerabilities. Personal experience also provides a compelling reason, my experience is ab…

I would expect memory safety vulns to be dropping in most C/C++ projects due to better practices

Re: Rust in Android: move fast and fix things

#32

Post by pizlonator »

littlestymaar wrote: post #12
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…

> 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 rollbacks, and less likely to be rewritten. I'd say that this is likely the most likely to be rewritten actually, because high test coverage is a massive enabler in such a rewrite, and because having a project that “…

> It's more of one additional anecdotal evidence that Rust is good.

But that means it's likely to be the worst kind of science:

- Group of people agree that Rust is good. This is a belief they hold.

- Same group of people feel the need to search for argument that their belief is good.

- The group does "science" like this.

And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion.

Re: Rust in Android: move fast and fix things

#35

Post by delusional »

I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both.

Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code written in 2022 actually increased, with rust not really having gained any significant momentum.

How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".

Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.

Re: Rust in Android: move fast and fix things

#36

Post by gpm »

littlestymaar wrote: post #10

> Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust, making it easier for Chromium engineers to deal with data from the web I find this surprising, isn't Wuffs[1] (also made by Google) an even better fit for this particular use-case? (It has compile-time spatial memory safety, where Rust has compile-time temporal safety but runtime spatial safety, with bound ch…

I don't find it surprising, just from barriers to adoption: "Wuffs programs take longer for a programmer to write, as they have to explicitly annotate their programs with proofs of safety" is a hard sell (even if it has obvious value) and "you have to learn and integrate yet another language just for parsing files" is a hard sell too.

Which isn't to say that it shouldn't be adopted (having not used it I really don't know), just that it's not surprising that it's having difficulty gaining traction.

Re: Rust in Android: move fast and fix things

#37

Post by tux3 »

beeflet wrote: post #13
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.

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.

>I think cargo is better than cmake

That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has.

There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track.

In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMake is to wish you didn't, that way someone else would have to maintain it.

Re: Rust in Android: move fast and fix things

#38

Post by quotemstr »

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.

Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using Rust or anything else so long as it plays by the rules.

Re: Rust in Android: move fast and fix things

#39

Post by selfmodruntime »

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.

Re: Rust in Android: move fast and fix things

#40

Post by gpm »

delusional wrote: post #35

I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both. Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code writt…

> How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".

The first graph considers vs languages, while the second graph considers C++ vs Rust. There's more languages than just those two in the first graph.

Moreover the first graph is in percentage terms, while the second graph is in absolute terms.

In 2022 it appears a bunch of memory safe non-rust code was added. Java/python/...

> Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.

That's a perfectly human phrasing lol.

Post reply on HN