5 ms·

Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1]. Google's recent analysis on

Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1]. Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the existing memory unsafe code they had. In practice, they found that vulnerability density in a stable codebase decays exponentially as you continue to fix bugs. So you can reap the benefits of built-in memory safety for new code while driving down latent memory unsafety in existing code to great effect. [2] [1]: https://www.alilleybrinker.com/blog/cpp-must-become-safer/ https://www.alilleybrinker.com/blog/cpp-must-become-safer/ [2]: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...

wyager 2y ago
> Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.
- alilleybrinker 2y ago
  There’s likely some amount of code which would not be rewritten into Rust but which would be rewritten into safe C++. Migrating to a whole new language is a much bigger lift than updating the compiler you’re already using and then modifying code to use things the newer compiler supports. Projects do the latter all the time.
- pavon 2y ago
  Why not? C++ has evolved over the years, and every C++ project I have worked on, we've adopted new features that make the language safer or clearer as they are supported by the compilers we target. It doesn't get applied to the entire codebase overnight, but all new code uses these features, refactors adopt them as much as possible, and classes of bugs found by static code scanning cause them to be adopted sprinkled through the rest of the code. Our C++ software is more stable than it has ever been because of it. Meanwhile, throwing everything away and rewriting it from scratch in another language has never been an option for any of those projects. Furthermore, even when there has been interest and buy-in to incrementally move to Rust in principle, in practice most of the time we evaluate using Rust for new features, the amount of existing code it must touch and the difficulty integrating Rust and C++ meant that we usually ended up using C++ instead. If features of Circle C++ were standardized, or at least stabilized with wider support, we would certainly start adopting them as well.
  - ameliaquining 2y ago
    What I'm really hoping is that https://github.com/google/crubit https://github.com/google/crubit eventually gets good enough to facilitate incremental migration of brownfield C++ codebases to Rust. That seems like it would address this concern.
  - safercplusplus 2y ago
    You might consider experimenting with the scpptool-enforced safe subset of C++ (my project). It should be even less disruptive. [1] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool
- safercplusplus 2y ago
  In theory it could be auto-converted to a safe subset of C++ [1]. In theory it could be done at build-time, like the sanitizers. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation2 https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
- gpderetta 2y ago
  The point is that it doesn't need to. According to google, making sure that new code is safe is good enough.
lmm 2y ago
Nah. The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking, as is the idea that a project could continue to provide useful functionality without vulnerabilities becoming newly exposed. And the idea of a meaningfully safer C++ is something that has been tried and failed for 20+ years. Eventually everything will be rewritten in Rust or successors thereof. It's the only approach that works, and the only approach that can work, and as the cost of bugs continues to increase, continuing to use memory-unsafe code will cease to be a viable option.
- gpderetta 2y ago
  > The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking yet the idea that a project no longer actively developed will be rewritten in rust is not?
  - lmm 2y ago
    > yet the idea that a project no longer actively developed will be rewritten in rust is not? Rewriting it in Rust while continuing to actively develop the project is a lot more plausible than keeping it in C++ and being able to "maintain a stable codebase" but somehow still fix bugs. (Keeping it in C++ and continuing active development is plausible, but means the project will continue to have major vulnerabilities)
    - bluGill 2y ago
      I'm not convinced. Rust is nice, but every time I think I should write this new code in Rust I discover it needs to interoperate with some C++ code. How to I work with std::vector<std::string> in rust - it isn't impossible but it isn't easy (and often requires copying data from C++ types to Rust types and back). How do I call a C++ virtual function from Rust? The above issue is why my code is nearly all C++ - C++ was the best choice we had 15 years ago and mixing languages is hard unless you limit yourself to C (unreasonably simple IMO). D is the only language I'm aware of that has a good C++ interoperability story (I haven't worked with D so I don't know how it works in practice). Rust is really interesting, but it is hard to go from finishing a "hello world" tutorial in Rust to putting Rust in a multi-million line C++ program.

wyager 2y ago

> Not everything will be rewritten in Rust. Yeah, but it's also not going to be rewritten in safe C++.

alilleybrinker 2y ago
There’s likely some amount of code which would not be rewritten into Rust but which would be rewritten into safe C++. Migrating to a whole new language is a much bigger lift than updating the compiler you’re already using and then modifying code to use things the newer compiler supports. Projects do the latter all the time.
pavon 2y ago
Why not? C++ has evolved over the years, and every C++ project I have worked on, we've adopted new features that make the language safer or clearer as they are supported by the compilers we target. It doesn't get applied to the entire codebase overnight, but all new code uses these features, refactors adopt them as much as possible, and classes of bugs found by static code scanning cause them to be adopted sprinkled through the rest of the code. Our C++ software is more stable than it has ever been because of it. Meanwhile, throwing everything away and rewriting it from scratch in another language has never been an option for any of those projects. Furthermore, even when there has been interest and buy-in to incrementally move to Rust in principle, in practice most of the time we evaluate using Rust for new features, the amount of existing code it must touch and the difficulty integrating Rust and C++ meant that we usually ended up using C++ instead. If features of Circle C++ were standardized, or at least stabilized with wider support, we would certainly start adopting them as well.
- ameliaquining 2y ago
  What I'm really hoping is that https://github.com/google/crubit https://github.com/google/crubit eventually gets good enough to facilitate incremental migration of brownfield C++ codebases to Rust. That seems like it would address this concern.
- safercplusplus 2y ago
  You might consider experimenting with the scpptool-enforced safe subset of C++ (my project). It should be even less disruptive. [1] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool
safercplusplus 2y ago
In theory it could be auto-converted to a safe subset of C++ [1]. In theory it could be done at build-time, like the sanitizers. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation2 https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
gpderetta 2y ago
The point is that it doesn't need to. According to google, making sure that new code is safe is good enough.

lmm 2y ago

Nah. The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking, as is the idea that a project could continue to provide useful functionality without vulnerabilities becoming newly exposed. And the idea of a meaningfully safer C++ is something that has been tried and failed for 20+ years. Eventually everything will be rewritten in Rust or successors thereof. It's the only approach that works, and the only approach that can work, and as the cost of bugs continues to increase, continuing to use memory-unsafe code will cease to be a viable option.

gpderetta 2y ago
> The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking yet the idea that a project no longer actively developed will be rewritten in rust is not?
- lmm 2y ago
  > yet the idea that a project no longer actively developed will be rewritten in rust is not? Rewriting it in Rust while continuing to actively develop the project is a lot more plausible than keeping it in C++ and being able to "maintain a stable codebase" but somehow still fix bugs. (Keeping it in C++ and continuing active development is plausible, but means the project will continue to have major vulnerabilities)
  - bluGill 2y ago
    I'm not convinced. Rust is nice, but every time I think I should write this new code in Rust I discover it needs to interoperate with some C++ code. How to I work with std::vector<std::string> in rust - it isn't impossible but it isn't easy (and often requires copying data from C++ types to Rust types and back). How do I call a C++ virtual function from Rust? The above issue is why my code is nearly all C++ - C++ was the best choice we had 15 years ago and mixing languages is hard unless you limit yourself to C (unreasonably simple IMO). D is the only language I'm aware of that has a good C++ interoperability story (I haven't worked with D so I don't know how it works in practice). Rust is really interesting, but it is hard to go from finishing a "hello world" tutorial in Rust to putting Rust in a multi-million line C++ program.