Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

171–180 of 430 posts

Re: Rust in Android: move fast and fix things

#171
post #30

Earlier quoted context omitted.

I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...

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.

>mention Go

>great error handling

why people so confident being so wrong???

Re: Rust in Android: move fast and fix things

#172
post #153

Earlier quoted context omitted.

Is it harder to learn than C? For sure it is a bit harder to get started. But is it also harder to learn than writing proper C(++?) with the same amount of quality in terms of lack of bugs ?

C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownersh…

How often do you DIY a self-balancing binary tree? Sure I wrote a few in college, but in the real world you are almost always just using an existing library. Optimizing for edge cases like that doesn't make sense.

And is your hand-written C implementation going to be safe and correct. You didn't mention any kind of locking or atomic operation, so is it going to unexpectedly break in a multithreaded environment?

The concepts of Rust are definitely more complicated, but in practice it just means that C makes it easier to shoot yourself in the foot. It's easy, but is that really the most important thing here?

Re: Rust in Android: move fast and fix things

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

They found a memory safety bug in their Rust code and assumed it was the only memory safety bug in their Rust codebase. And then they compared it to the historical average in C++ code that's been around for almost two decades in production. I can't be the only one here who sees how biased this comparison is right?

If you want something more comparable, they estimate that only 5% of their Rust code is within unsafe blocks. That makes only 5% of the code with potential for memory safety issues: that's already a 20x improvement. Let's make it 10x because unsafe blocks tend to be trickier, but you still get a lot of Rust guarantees.

The thing is with Rust, you know where to look for memory safety issues: the unsafe blocks. C and C++? GLHF that's your whole codebase. As they mentioned, you don't opt-out of all of Rust guarantees by going the unsafe route. Of course you can ditch them, but that'll be hugely visible during code review. Overall, you can be much more confident saying "yup there's no bug there" in Rust than in C or C++.

Re: Rust in Android: move fast and fix things

#174

Earlier quoted context omitted.

>It's all nonsense, How is any of that wrong?

1. You don't know what you're doing - everyone makes mistakes. 2. You can still write bugs in Rust but the point is you are far less likely to.

Yeah but 1000x less mistake ????? I mean these people behind android project is atleast one of the better engineer but jesus christ if they can improve so much then I dont know how much average joe can benefit from that

Re: Rust in Android: move fast and fix things

#175
post #96

Earlier quoted context omitted.

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?

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

If rust were invented in the 90s, it wouldn’t have used llvm. Rust could still have been implemented, and we’d probably have a much faster compiler as a result. But it would have missed out on all the benefits of llvm too. It would have needed its own backend to be written - which would have been more work. And the compiler probably wouldn’t have been as good at low level optimisations. And it probably wouldn’t have out of the box support for so many target platforms. At least, not from day 1.

Re: Rust in Android: move fast and fix things

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

To be honest I feel like "this code is easier to review and less likely to require rollbacks" is even more of a valuable take from this article, just in terms of "hey, don't you like it when things don't have to be rolled back?"

Security issues are like bad etc too, just we've heard the security spiel so many times at this point. I just think it's nicer to write most stuff in Rust.

Re: Rust in Android: move fast and fix things

#177
post #30

Earlier quoted context omitted.

I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...

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.

How is Go memory safe? Memory safety does not mean "leaking memory".

It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way.

I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bounds is not possible. But it is by no means "memory safe" to the level Rust is.

Re: Rust in Android: move fast and fix things

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

They found a memory safety bug in their Rust code and assumed it was the only memory safety bug in their Rust codebase. And then they compared it to the historical average in C++ code that's been around for almost two decades in production. I can't be the only one here who sees how biased this comparison is right?

and they found 1000 memory safety bugs and assumed it was the only 1000 memory safety bugs in that code which have been in production for 2 decades. How naive can they be?

Re: Rust in Android: move fast and fix things

#179

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…

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 been making history ever since. I think Rust got critical mass because it had a bold vision and focused on developer experience enough to get buy in on improving its performance and robustness. Ada is wonderful, but it's less pretty, and doesn't make pretensions. In that sense, Rust was built for the hype, but the language has benefitted greatly from all the attention.

Re: Rust in Android: move fast and fix things

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

Those are orange vs apple, just like the rate of rollbacks

They compare something new, which rewrite existing stuff (not only but still) with some decades-years-old cruft

In they new code, they know what they want

They can also start with state-of-the-art unit testing that may not exist in the early 2000

So .. yeah, those numbers ..

That rust is saner than c++ is a given anyway :)

Post reply on HN