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

271–280 of 430 posts

Re: Rust in Android: move fast and fix things

#271

Post by baq »

ActorNightly wrote: post #107
petcat wrote: post #7

At this point I feel like it's no longer an uphill climb to get Rust into foundational, mission-critical code adoption. The benefits are so obvious. Maybe it's just a lingering religious war? In any case, I'm glad we're seeing more and more evidence and case-studies of why "rewrite it in Rust" isn't just a meme.

Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper. That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing…

> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.

I sense a lack of statistical education here.

Re: Rust in Android: move fast and fix things

#272

Post by baq »

duped wrote: post #108
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…

I think Rust is easier to learn than C++

C++ is the hardest, most difficult programming language to write correct (according to spec, not in the ‘it compiles’ sense) programs in ever created that isn’t a toy or specifically designed to be hard like malbolge. It takes a decade of writing it daily to realize that you know nothing, precisely because the compiler does not reject so many invalid programs.

Re: Rust in Android: move fast and fix things

#273

Post by baq »

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…

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

Who do you think AI learned it from

Re: Rust in Android: move fast and fix things

#274

Post by SkiFire13 »

lmm wrote: post #183
teaearlgraycold wrote: post #125

Earlier quoted context omitted.

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?

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

Rust also has the bigger numbers on microbenchmarks, that's why people care about it.

Re: Rust in Android: move fast and fix things

#275

Post by lmm »

SkiFire13 wrote: post #274
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.

Rust also has the bigger numbers on microbenchmarks, that's why people care about it.

Yes, exactly. It's tragic that the only way programming culture ever improves is when a language comes out that's better for writing software in and happens to also have bigger numbers on microbenchmarks.

Re: Rust in Android: move fast and fix things

#276

Post by SkiFire13 »

samdoesnothing wrote: post #209
kibwen wrote: post #163

Earlier quoted context omitted.

Rather, they found one memory safety bug in their Rust codebase, and measured it against the legions of memory safety bugs they found in their C++ codebase. In neither case are they measuring against bugs not found, so no, it's not biased.

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.

> The C++ code has been around a lot longer

They made an earlier report where they found out that older C/C++ code has actually a lot less new vulnerabilities compared to new code, so I guess here they are comparing to new C/C++ code to get the higher ratio, meaning the comparison should actually be apples-to-apples.

Re: Rust in Android: move fast and fix things

#277

Post by timeon »

samdoesnothing wrote: post #245
shakow wrote: post #218

Earlier quoted context omitted.

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.

Where is your data? You seem to be biased.

Re: Rust in Android: move fast and fix things

#278

Post by blub »

josephg wrote: post #170
dgacmu wrote: post #159

Earlier quoted context omitted.

Rust is more difficult to learn the basics of than C, but I'm not sure it's more difficult to learn to write memory-safe code in Rust than in C. It's also not clear to me it's that much harder to learn Rust than it is to learn how to write equivalently-high-level code in C++ _unless you end up in one of the areas where Rust is really hard_. But a lot of systems code doesn't end up in those areas. Some does, and then…

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…

The pain will always remain when refactoring or changing code, with modifications cascading in the function and type definitions.

If a language is hard to write at first, it’s always hard to write. The saving grace of C++ is that one mustn’t use the overcomplicated functional aspects, template meta-programming, etc. Through some amazing circumstances, all of the above (or their equivalents) + async is exactly what idiomatic Rust code has become.

Inside Rust there is a not so ugly language that is struggling to come to light and it is being blocked at every step.

Re: Rust in Android: move fast and fix things

#279

Post by littlestymaar »

pizlonator wrote: post #58
dwattttt wrote: post #47

Earlier quoted context omitted.

> 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. Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?

In science, you go out of your way to control for confounding factors. This isn't that.

I'm the first one to be annoyed when political scientists and economists pretend to do science when they are just extrapolating from anecdotal correlations, but here this isn't something being published in a scientific journal and nobody claim they are doing “science” in the first place.

Re: Rust in Android: move fast and fix things

#280

Post by baq »

array_key_first wrote: post #208
IncreasePosts wrote: post #184

Earlier quoted context omitted.

Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that…

The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus . C is not simple, it is inept. There are so, so many bargain-bin features and capabilities that it just cannot do that it ends up creating much MORE complex code, not less complex code. I mean, just the pretense tha…

> The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.

This, this, this.

C compilers are simple, but the C language is not, and let’s not even talk about C++.

Post reply on HN