[noxs]

Meanwhile the author also says this

> Rust would have prevented this incident irks me.

That's exactly everyone's point.

and

> Think of… an innocent buggy unwrap() call if the code actually used Rust.

Sure but would you not just ban usages of unwrap with static lint for a kernel program?

This is more or less like clickbait to me.

[uecker]

The point is that merely using Rust would not automatically prevent this problem. Of course you could use Rust and forbid all unwrap(). But then question is why you could not forbid all unchecked dereferences (e.g. ensured with static analysis) in C/C++. The problem with C/C++ is not that this is impossible, it is that this is not done.

[nindalf]

Anything is possible in theory. In practice Rust codebases have high standards because it is easy to set up. For instance, most production users use clippy, which has a lint that will tell you if you're using unwrap() outside of test code. Clippy is so easy to set up, that you'd be silly not to. And this in addition to all the checks the compiler does for you for free.

To answer your question - it's much easier to fall into the pit of success when using Rust.

Sure C++ users could set up ASAN, UBSAN etc., but it's extra effort and many people don't bother.

[capitainenemo]

And based on what I've read over the years here on HN those compile and run-time tools still are limited by the language and have known failure modes that rust checks would not have.

[uecker]

I am not really convinced. I could easily see Rust in the wild be full of unwrap, unsafe, etc.. if written by people that do not bother but are forced to use Rust.

And then, what is even the right behavior for a kernel driver that encounters an unexpected problem related to input? In the interest of security you might want it to crash the machine instead of continuing. I think panic is the default in Rust for many error cases - and I think this is the right approach, but it would have led to exactly the same result in this case.