alt Hacker NewsCounterpoint, more than memory bugs exist, and everything's written in C. You're welcome to rewrite in Rust but you'll create countless bugs that aren't memory bugs that mostly already got fixed in the C version. I can't help but think things like fil-C are the most pragmatic route, despite performance costs, for most people relying on programs written in C.
Replies
This is a dumb argument imo. Critical vulnerabilities are mostly due to memory bugs (and not for a lack of other kinds of bugs). Most people relying on programs written in C (or even C++) should consider plans for migrating to software created with toolchains from this century. You cannot indefinitely carry on this tech debt.
I'm not suggesting anything like "rewrite in Rust", at least not in general. I'm simply poking at the fact that use-after-free (and other such issues) are effectively deprecated classes of bugs.
Yes, you'd introduce a lot of new bugs because the code is newly written[1], but eventually you'll get to the same maturity as today except you can't have all these devastating memory-handling-related vulnerabilities
The question is whether your software will be in use long enough to be worth the cost of change more than whether it's a good idea in the long run. For Linux, I'd argue that that's likely. At least new code would ideally be contributed in a safe language, where practically possible (there'll surely be places where you need to deal with memory as a kernel)
Relevant article: reducing memory vulnerabilities through a combination of memory-safe languages and an exponential decrease of bugs as existing code ages https://security.googleblog.com/2024/09/eliminating-memory-s..., from which I'll also quote my reference for [1]: "A large-scale study of vulnerability lifetimes published in 2022 in Usenix Security [...] found that the vast majority of vulnerabilities reside in new or recently modified code"