Hacker News new | ask | show | jobs
by AlotOfReading 183 days ago
Where did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in Rust code and I don't think there's a realistic argument that the experiment has been anything other than successful.
1 comments

Was it? It seems more a fantastic demonstration how the same type of errors can also occur in Rust code.
In C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google:

https://security.googleblog.com/2025/11/rust-in-android-move...

But don't take my word for it, you can hear about the benefits of Rust directly from GKH:

www.youtube.com/watch?v=HX0GH-YJbGw

There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.

Hey, it was my point that the number of CVEs is red herring.

And no, I do not care or even believe what Google says. There are so many influencing factors.

I would expect that the largest factor is cultural, and of course it's possible to inculcate safety culture in a team working on a C or C++ codebase, but it seems to me that we've shown it's actually easier to import the culture with a language which supports it.

Essentially Weak Sapir–Whorf but for programming languages rather than natural languages. Which is such a common idea that it's the subject of a Turing Award speech. Because the code you read and write in Rust usually has these desirable safety properties, that's how you tend to end up thinking about the problems expressed in that code. You could think this way in C, or C++ but the provided tooling and standard libraries don't support that way of using them so well.

The thing is. There always was a strong theoretical case that Rust should improve software quality (not just because of the fact that you have a lifetime system). The only reasonable counterpoint was that this is theory, and large scale experience is missing. Maybe in high quality code bases the mental overhead of using Rust would outweigh the theoretical guarantees, and the type of mistakes prevented are already caught by C/C++ tooling anyways?

The (in recent years) rapid adoption of Rust in industry clearly shows that this is not the case.