[simonask]

You have a wild amount of confirmation bias going on here, though.

Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.

The promise of Rust was never that it is magical. The promise is that it is significantly easier to manage these types of problems.

[uecker]

There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did.

Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen.

I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.

[ivanbakel]

> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs."

Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible.

If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.

[uecker]

Yes, but this is the marketing bullshit I am calling out. "Safe Rust" != "Rust" and it is not "Safe Rust" which is competing with C it is "Rust".

[ivanbakel]

> it is not "Safe Rust" which is competing with C it is "Rust".

It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power.

Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive throughout the program. That’s a significant difference from how C’s unsafety works.

[uecker]

But there are more than 2000 uses of "unsafe" even in the tiny amount of Rust use in the Linux kernel. And you would need to compare to C code where an equally amount of effort was done to develop safe abstractions. So essentially this is part of the fallacy Rust marketing exploits: comparing an idealized "Safe Rust" scenario compared to real-word resource-constrained usage of C by overworked maintainers.

[Daishiman]

The C code comparison exists because people have written DRM drivers in Rust that were of exceedengly high quality and safety compared to the C equivalents.

[simonask]

This is just so obtuse. Be serious.

Even if you somehow manage to ignore the very obvious theoretical argument why it works, the amount of quantitative evidence at this point is staggering: Rust, including unsafe warts and all, substantially improve the ability of any competent team to deliver working software. By a huge margin.

This is the programming equivalent of vaccine denialism.

[uecker]

There is a lot of science showing vaccines work. For Rust showing that it is better this is still lacking. And no Google's blog posts are not science.

[Daishiman]

So kernel devs claiming Rust works isn't good enough? CloudFlare? Mozilla? Your're raising the bar to a place where no software will be good enough for you.

[UltraSane]

Safe Rust absolutely eliminates entire categories of bugs

[yourdetect]

> Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.

The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in order to avoid UB.

[yencabulator]

The unsafe code relied on an assumption that was not true; the chosen fix was to make that assumption be true. Makes perfect sense to me.

[simonask]

Rust fanboys on Reddit are not contributing to the Linux kernel. What matters here is that Rust helps serious people deliver great code.