Why you should, actually, rewrite some of it in Rust
Sigh. This again.<p>Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom.<p>Heartbleed is a great example. It wasn&#x27;t caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn&#x27;t going to help you with that.<p>Could the affected parts be re-written in a way where the boundary checks would have worked? Yes. As they could have in C, C++, D, Fortran, or any number of other languages.<p>If memory safety and correctness was so truly valued above everything else, we&#x27;d be seeing a lot more Ada than we do today.<p>And this doesn&#x27;t even cover the fact that not everything <i>can</i> be re-written in Rust, mainly due to compilation target restrictions.<p>Exasperated Edit: No, I&#x27;m not saying code should never be re-written. I&#x27;m not even saying that Rust is a bad tool if the decision to re-write is made. What I am saying is that Rust is not a silver bullet. Rust is not going to solve every problem ever. Rust is one of many choices for writing memory safe, C ABI compatible code.<p>The reasons provided by this article are insufficient to solely justify a re-write in Rust; the exact same arguments could be used as justification for rewriting everything in Ada. Or Haskell. Perhaps some thought will be put in the next &quot;re-write everything in Rust&quot; article that takes that into account.<p>Then again, none of the past articles have.