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

281–290 of 430 posts

Re: Rust in Android: move fast and fix things

#281

Post by manmal »

ModernMech wrote: post #81
manmal wrote: post #75

Earlier quoted context omitted.

Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever. Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further b…

Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.

I fully, totally agree with this. The recent fixes for concurrency makes Swift look like a poor man’s Rust anyway.

Re: Rust in Android: move fast and fix things

#282

Post by Jweb_Guru »

stocksinsmocks wrote: post #250
vacuity wrote: post #179

Earlier quoted context omitted.

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

The history is kind of weird. Graydon was ejected out of his own language and then a machine took over. That is really unusual, and I’m not sure there is an analog anywhere.

> Graydon was ejected out of his own language

That's not what happened at all. Graydon voluntarily stepped down because he didn't want to be in the role of BDFL. It's true that he wasn't a huge fan of the "C++-ification" of the language, but he wasn't pushed out or anything, and definitely could have stayed on steering the project as long as he wanted to. I think there are a number of other languages that would have benefited from a similar approach, actually.

Re: Rust in Android: move fast and fix things

#283

Post by baq »

linkage wrote: post #156
spockz wrote: 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…

> to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.

It is misguided to say that recursive data structures should be easy to write. They are difficult to reason about and the Rust compiler is right to point this out. CS is not engineering, you should be writing those trees with a pencil on a piece of paper as Dijkstra intended, not in C.

Re: Rust in Android: move fast and fix things

#284

Post by littlestymaar »

nicoburns wrote: post #101
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…

If you're parsing untrusted data, then some level of runtime checking is unavoidable. And Rust's pretty good at letting you encode "I already checked this and therefore don't need to check it again" into the type system.

Rust is good, don't get me wrong, but bound checks are still reason why you occasionally need unsafe to get the maximum performance, because not everything can be expressed as an iterator where bound checks are automatically eliminated.

If you check Wuffs repo, you'll see benchmarks very favorably comparing to rust implementations.

And it's not surprising, wuffs is to spatial safety what the borrow checker is to temporal safety. And regarding spatial safety rust is kind of like where C++ is in terms of temporal safety: it has the choice between unsafe or runtime check hopping that a large fraction of them will get eliminated by the compiler.

Re: Rust in Android: move fast and fix things

#285

Post by baq »

linkage wrote: post #166
kibwen wrote: post #157

Earlier quoted context omitted.

> Because it's not a silver bullet. It does look like a silver bullet, actually. In the context of software engineering, "silver bullet" inevitably leads to Fred Brooks: '"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or manag…

[flagged]

> paper reports three orders of magnitude less issues, cites evidence

> baseless claims

Not even downvoting.

Re: Rust in Android: move fast and fix things

#287

Post by Jweb_Guru »

vacuity wrote: post #158
whyever wrote: post #136

Earlier quoted context omitted.

Note that N=1 for the memory safety vulnerabilities they had with Rust, so the error of the estimated average number of vulnerabilities per LOC is quite large.

Yes. I would make a guess of 10 or less memory-safety vulnerabilities per MLOC, which is still a hundredfold reduction.

Your best guess is that the true rate is 20x higher than the observed rate? This seems unlikely to me given the number of samples (outside of systematic biases towards certain types of memory safety bugs that probably apply to C++ code too). 10 per hundred MLOC is closer to what I would have guessed too, but that is because I've historically been very conservative with my assumptions about the memory unsafety rate per unsafe LOC being similar to that of C++. The evidence here suggests that the true rate is probably much lower than that.

Re: Rust in Android: move fast and fix things

#288

Post by blub »

oconnor663 wrote: post #261
belval wrote: post #116

Earlier quoted context omitted.

Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.

Take a look at the examples in this post: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... Large C++ codebases have the same problems that large codebases have in any language: too many abstractions, inconsistent ways of doing things, layers of legacy. It comes with the job. The difference is that in C/C++, hard-to-read code also means hard-to-guess pointer lifetimes.

If the C++ code I worked on looked like that[1] and was actually C with classes, then I’d be switching to Rust too. For Google and Microsoft it probably makes sense to rewrite Windows and Android in Rust. They have huge amounts of legacy code and everybody’s attacking them.

It doesn’t follow that anyone else, or the majority has to follow then. But that’s predictably exactly what veteran rustafarians are arguing in many comments in this thread.

[1] Pointers getting passed all over the place, direct indexing into arrays or pointers, C-style casts, static casts. That (PVOID)(UINT_PTR) with offsetting and then copying is ridiculous.

Re: Rust in Android: move fast and fix things

#289

Post by raxxorraxor »

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.

I fear Androids problems with Google as steward has other significant problems than memory safety.

To a degree that users might want to even exploit such flaws to unlock their phones.

Aside from that. Sure, the constraints of Rust do solve these kinds of problems.

Re: Rust in Android: move fast and fix things

#290

Post by flohofwoe »

cogman10 wrote: post #225
flohofwoe wrote: post #67

Earlier quoted context omitted.

The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.

I'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated. [1] https://github.com/android/ndk-samples/tree/main/endless-tun...

Both Gradle and CMake have a strong late 1990's smell to them. While CMake is sort of a necessary evil in the C/C++ world, there's no excuse for dragging Gradle into the NDK, combining both build tools leads to a complexity explosion that rarely works and tends to break after either the NDK or SDK is updated, or somebody merely looks the wrong way at the build files.
Post reply on HN