Realistically, three of those 5 points are non-issues for C/C++ devs. The last is only relevant for certain types of workload. So you’re left with one real killer-feature of Rust: the safety. It’s a massive feature that cascades very well into pretty much anything you do... but it’s also one feature really - the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago (in their own ad-hoc ways). So the cost-benefit analysis of moving an existing codebase from C/C++ to Rust is not exactly a slam-dunk.
For greenfield, though, my feeling is that one should justify why not using Rust, at this point (when building stuff that was previously the realm of C/C++, of course). If it’s just because of unfamiliarity and initial slow speed of development (as people learn it), it becomes an issue of institutional laziness more than a technical choice.
> 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.
> addressed that problem a long time ago (in their own ad-hoc ways)
I think it's becoming increasingly clear that "addressing the problem" in C and C++ means fixing all the memory safety issues you know about. Sqlite is the posterchild of careful testing in a C codebase, and they had a serious CVE last year. Realistically, the vast majority of C and C++ projects have more bugs than that, even if they're staffed by experts who take security seriously.
But I agree with you about the cost-benefit analysis. It's not very often that security issues destroy an entire company, and trying to rewrite a large codebase might be existentially riskier more often than not.
I think the more interesting cost benefit isn't moving from C++ to rust. Rather it is moving from Java or Python or Ruby or Perl to Rust.
You'd pretty much never make the move from Java -> C++ because of the lack of safety. But you may want to do it because of the other non-safety features.
That is where Rust is interesting and competitive. It's the performance and memory footprint of C++ with the memory safety of Java.
For greenfield, though, my feeling is that one should justify why not using Rust, at this point (when building stuff that was previously the realm of C/C++, of course). If it’s just because of unfamiliarity and initial slow speed of development (as people learn it), it becomes an issue of institutional laziness more than a technical choice.