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

[gamerk2]

To sum up my two biggest concerns:

* C++ won't stop you from reading memory from Thread A while writing from Thread B. rust does, at compile time.
* C++ won't stop you from using references, which became invalid.

C++ allows a lot of bad practises; C even more. It's not particularly hard to write bad/unsafe code. The trick is to "not" do that. C/C++ gives the ability to do a LOT of powerful operations at a very high performance level relative to other languages, but those same features are downright dangerous if misused. But that's why C-derived languages have survived so long: despite their MANY pitfalls, it offers the highest level of performance relative to the effort required to code.

[smitty3268]

You are conveniently grabbing onto a single example that happens to not contradict your point.

You're doing the same thing, though.

Do you mean in all those 2.3M lines of code, all the original C++ was already free of bugs and it was never Mozilla's intention to solve vulnerabilities, but only better multithreading?

I don't think that's at all what was being said.

The truth of the matter is that rewriting heavily used code almost always introduces new bugs. That's the reason it should only be done for good reasons, and not just on a whim. Old code has generally had lots of users reporting lots of bugs against it, and hopefully had most of those fixed. New code is always going to have some silly mistakes in it, because people aren't perfect. Hopefully moving forward those bug numbers will get even lower, and it will allow for new features/etc. to be added on while not raising the bug numbers too high again.

If Mozilla really did replace c++ code with a rewritten Rust version and had no change in the # of bugs being found, I'd consider that a massive win. But I'd also say that what's been reported so far on that here isn't nearly specific enough to argue that's what happened one way or another. I think the subject needs way more detailed analysis to take anything away from it one way or another. Just spitballing a couple project-wide stats is pretty useless.

[ultimA]

I don't think that's at all what was being said.

Of course not and I know that too. This was a rhetorical question, meant to point out how wrong their argument is. Because if it was true what they said earlier, this is what it would imply.

The truth of the matter is that rewriting heavily used code almost always introduces new bugs. That's the reason it should only be done for good reasons, and not just on a whim. Old code has generally had lots of users reporting lots of bugs against it, and hopefully had most of those fixed. New code is always going to have some silly mistakes in it, because people aren't perfect. Hopefully moving forward those bug numbers will get even lower, and it will allow for new features/etc. to be added on while not raising the bug numbers too high again.

If Mozilla really did replace c++ code with a rewritten Rust version and had no change in the # of bugs being found, I'd consider that a massive win. But I'd also say that what's been reported so far on that here isn't nearly specific enough to argue that's what happened one way or another. I think the subject needs way more detailed analysis to take anything away from it one way or another. Just spitballing a couple project-wide stats is pretty useless.

It seems there is a slight misunderstanding. I didn't say that the bug count for Firefox didn't change after the rewrite. Or anything about whether it changed or in what direction. That is, as you say, hard to tell from such statistics. What I've been pointing out in this thread is that Firefox still has a similar ratio of memory- to non-memory-related CVEs as projects with no Rust at all, even though Firefox has a significant portion of its code written in Rust now. That can only mean one of two things: 1) Either CVE statistics are a bad indicator for the portion of memory-related issues in software, that would mean though the often quoted numbers from similar sources that should prove how bad C++ is are garbage too. 2) Or it could mean Rust is not a magic bullet either when it comes to memory safety. And yes, maybe such issues in Rust all come from unsafe code - I never contradicted that - but if this is the case, I do think this has a lot of implications for Rust codebases, such as the practicality of writing pure-safe code in non-toy projects, or whether Rust's overall security impact is exaggerated in big real-world projects.