Hacker News new | ask | show | jobs
by johncolanduoni 183 days ago
One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just enforced bounds checks would catch lots of bugs that (normal, non-verified) C would miss? Do you doubt that Python code corrupts memory a lot less because you saw a CPython CVE once?

What language do you think Graydon Hoare was spending most of this time writing while he started working of Rust as a side project? Hint: it sure wasn’t Java. Rust is not the product of some developer who has only used 2 scripting languages and had to read the definition of stack-smashing off of Wikipedia showing those C developers how to live in the future. It’s not old enough for many of the developers working on it to have only ever used Rust. It’s mostly C and C++ developers trying to build a new option for solving their same problems.

2 comments

> It’s mostly C and C++ developers trying to build a new option for solving their same problems.

I've observed that a lot of the folks I used to meet at ruby conferences have moved to Rust. No idea what led to this, but maybe it's just folks that were generally curious about new programming languages that moved to ruby when it became better known and that the same interest led to adopting Rust.

I worked on a Ruby codebase that moved to Rust - I think that part is mostly cargo-culting cool things in the news to be perfectly honest. There’s type safety advantages, but if Ruby’s performance envelope was even conceivably acceptable for your use-case there are likely better options. I strongly suspect a lot of the friction between Rust and only-C/C++ developers is the product of a bunch of people coming at Rust from higher level languages parroting lines about safety, and then looking at you blankly if you ask how it handles nested pointer indirection.

But I don’t think that applies to the people actually driving the language forward, just those talking a big game on HN/Reddit.

Giving the size and age of the C ecosystem, the number of bugs is not really a valid argument. We will see an increasing numbers with Rust as Rust is increasingly used. I also do not question that Rust solves some problems. It just solves them rather badly and at high cost while bringing new problems.

I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that this motivated starting something new, but it was not a clean C code base (and not even C).

What number of CVEs is Rust kernel code allowed to have before we have good evidence it’s a categorical failure? Do you turn off KASLR for your Linux machines because there exist CVEs it doesn’t protect against?
As long as the kernel will be developed, there will be CVEs - even with Rust. So at what point the number is so high that we should drop Rust and move to formal verification? And even then, there will be CVEs... This whole argument is nonsense.

But I also do not agree that memory safety is of much higher importance than other issues. Memory safety is highly critical if you have a monopolistic walled garden spyware ecosystem - such as Android. Not that I do not want memory safety, but the people I know who got hacked, did not get hacked because of memory safety issue, but because of weak passwords or unpatched software. And at least the later problems gets harder with Rust...

Your priorities do not match that of most kernel developers or most operators of network-connected Linux systems (even if we ignore Android). So I don’t think your problem is with Rust at all, you’ll need to fork Linux if you want the project to stop putting huge amounts of effort into memory safety (as it has for decades).
You are right, I do not have a problem with Rust as a language nor with the kernel improving memory safety. My issue is solely with exaggerated claims and aggressive marketing of Rust.

(And I am operating network-connected Linux devices since 30 years myself. Memory safety is not the known issue, at the moment I worry more about limited security updates due to Rust.)

The number of memory related bugs is absolutely a valid issue with C when the same bugs are impossible in Rust. The C memory model is a disaster when every computer is connected to the Internet.
You are saying the Rust bug in the kernel was impossible? How did it happen then? Come on guys.