> the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago
It's quite the opposite: the larger a C/C++ project gets, the more problem you are starting to have with safety. Securing and modifying millions of lines of C/C++ code (especially if it's multi-threaded) is a nightmare, and actually impossible, where people are afraid to refactor old code because all the ownership uncertanities.
Rust changes a global ownership tracking problem to a local one.
But if you can’t have a Big Rewrite, you’re looking at meshing Rust and C/C++ - a suboptimal situation for any language, regardless of ease of technical integration, because of the organizational overhead (now you need to hire developers proficient in both C and Rust, rather than just one of them, and have two sets of standards, two sets of onboarding procedures, etc).
To clarify, I’m not arguing that Rust is bad or inferior (to the contrary!), just that the incentives for established projects to move on from C/C++, from a strategic perspective, might not look that massive if they’re only gaining in safety.
Big companies already use microservices to separate programs (and be sane with memory ownership), so the logical way to move to Rust is to write new microservices in Rust.
It's quite the opposite: the larger a C/C++ project gets, the more problem you are starting to have with safety. Securing and modifying millions of lines of C/C++ code (especially if it's multi-threaded) is a nightmare, and actually impossible, where people are afraid to refactor old code because all the ownership uncertanities.
Rust changes a global ownership tracking problem to a local one.