Rust doesn't solve the CrowdStrike outage

Re:Rust doesn't solve the CrowdStrike outage by nindalf on Tuesday July 23, 2024 @01:27PM (#41048611)

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.

[ Parent | on HN ]

Re:Rust doesn't solve the CrowdStrike outage by uecker on Tuesday July 23, 2024 @02:26PM (#41049213)

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.

[ Parent | on HN ]

Re:Rust doesn't solve the CrowdStrike outage by nindalf on Tuesday July 23, 2024 @05:43PM (#41051275)

Yes in theory a person could write poor Rust code. But in practice the quality of popular Rust libraries is pretty high.

Linus says you never crash in the kernel, which is why Rust code merged into Linux won’t crash.

[ Parent | on HN ]

Re:Rust doesn't solve the CrowdStrike outage by capitainenemo on Tuesday July 23, 2024 @02:02PM (#41048967)

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.

[ Parent | on HN ]