Latest Patches Sent Out For Adding Rust Support To The Linux Kernel

[ferry]

So no, rust doesn't make your programs magically bug-free. But it usually eliminates one source of bugs.

The statistics suggest memory bugs are reduced at the expense of logic bugs, resulting to approximately the same amount of CVE's.

[Alliancemd]

For the first time in my life I am actually curious and excited about writing a kernel driver.

[krzyzowiec]

But is Rust's security really that much better? -O3 is irrelevant (I don't care about that either), but as for security, real world shows Rust's most advertised feature, its "better security compared to C++" is very limited and over-estimated. There is no shortage of memory memory-related CVEs in Rust crates, both double-drops/frees and dereference of invalid memory. See link below.
Or even more shocking, Firefox has about 20% of its native code in Rust, yet the share of memory-related CVEs (percentage-wise) is basically still the same as in any other non-Rust project (about 70%).

Yes it’s still much better because those double frees are only happening in unsafe blocks, so unlike C, in Rust you know where to look if there are problems.

Basically it’s not in the Rust code, it’s in the parts marked unsafe because you are doing C like things in them, such as manual pointer manipulation.

[mdedetrich]

The statistics suggest memory bugs are reduced at the expense of logic bugs, resulting to approximately the same amount of CVE's.

Uh what?

[ssokolow]

Rust usually has tighter APIs, enabling devs to reason more locally without having to check foreign code or manually uphold invariants as much as C++.

This phrase needs to be emphasized more, because it's one of the big, important design goals of Rust.

[moltonel]

The statistics suggest memory bugs are reduced at the expense of logic bugs, resulting to approximately the same amount of CVE's.

That's a uselessly weak proof. You have one bit of information (amount of rust code in Firefox) on a complex project and a very noisy bit of data (number of Firefox CVEs of all kinds) and deduce a causal link and even a simplistic explanation for the surprising data ("if it's not Rust memory bugs it must be Rust logic bugs"). This is a naive view on a complex subject, that fell prey to availability bias and motivated reasoning.

FWIW, I find it easier to model my logic in Rust than in C++, suggesting less logic bugs in my Rust code, thanks to Rust enums (akin to C++ tagged union, but better and deeply idiomatic), Result type instead of exceptions, more explicit mutability, traits instead of inheritance, a stronger community push towards foolproof APIs, etc.

[mdedetrich]

That's a uselessly weak proof. You have one bit of information (amount of rust code in Firefox) on a complex project and a very noisy bit of data (number of Firefox CVEs of all kinds) and deduce a causal link and even a simplistic explanation for the surprising data ("if it's not Rust memory bugs it must be Rust logic bugs"). This is a naive view on a complex subject, that fell prey to availability bias and motivated reasoning.

FWIW, I find it easier to model my logic in Rust than in C++, suggesting less logic bugs in my Rust code, thanks to Rust enums (akin to C++ tagged union, but better and deeply idiomatic), Result type instead of exceptions, more explicit mutability, traits instead of inheritance, a stronger community push towards foolproof APIs, etc.

I would argue its downright deceptive/misleading and anyone with a faint objective understanding of how statistics works would have shot such a shoddy conclusion down the drain.

[aspen]

I'll get me popcorn.

it's like a curse, almost any article related to Rust on this site will have a shitshow in the comments (and sometimes even someone complaining about the LLVM for no good reason!)

[ultimA]

mdedetrich You come and accuse people of being deceptive, shoddy, not having even the faintest understanding etc. but the fact is it is perfectly logical: If you replace a significant percentage of a codebase with code that in theory eliminates a large category of errors, then it is perfectly sane logic to expect that the reduction of errors should be visible in statistics after the rewrite. Yet it isn't. And none of you has provided an explanation why this shouldn't be the case, only just blank claims that "it isn't and that's it". That's real bias, but from your part! Give a logical explanation, until then you seem the be the one being deceptive and shoddy (to use your own words). Of course the conclusion wasn't "shot down the drain" right in the beginning, owning to the fact that nobody could yet provide any other reasonable explanation. I'm not saying there isn't any, but if there is, it is obviously counterintuitive and non-obvious, and since you yourself haven't yet been to explain it, despite taking part in the discussion actively for some time, go and shove your personal insults "down the drain".

The statistics are noisy or wrong? Don't they truly represent the portion of bugs? Possibly, but then how come you use the same statistics to point out how buggy C++ software is? The answer is of course, the statistics are correct when it proves your point, but become magically wrong otherwise. Again, stop with personal accusations and explain the phenomenon instead of being a stuck-up know-it-all who must be believed in.

[mdedetrich]

mdedetrich You come and accuse people of being deceptive, shoddy, not having even the faintest understanding etc. but the fact is it is perfectly logical: If you replace a significant percentage of a codebase with code that in theory eliminates a large category of errors, then it is perfectly sane logic to expect that the reduction of errors should be visible in statistics after the rewrite.

No its not, because its also entirely possible that the code replaced didn't happen to have any bugs because most were ironed out over 10-15 years with plenty of bugs reports/security breaches/CVE's in the past (we are talking about Firefox here). The difference here being that it took Firefox 10-15 years to discover/get rid of said bugs where as a lot of those wouldn't have even compiled in Rust.

Also in some cases, the Rust code replacing the Firefox code wasn't like for like, i.e. the multithreaded/GPU CSS render Quantum was replacing a basic single threaded/CPU CSS render (which stayed single threaded because of how terrible C/C++ is when it comes to multithreaded code, a convenient thing you ignored when claiming that C++ is as good as Rust, its not). The C++ code in Firefox was so bad that people were scared to touch it when it came to major features because of a high chance of introducing security vulnerabilities/bugs which is actually funnily enough the reason why those same Firefox devs came up with Rust, its because of how crappy it was dealing with C++ (and Firefox is one of the biggest C++ codebases out there, aside from Chromium).

Great job demonstrating how both of you guys are more concerned about proving a point rather than being accurate, queue in a golf clap.