Safety may seem like a binary property, but it's really not.
Modern C++ is not as safe as Rust, but it is much safer than C, and significantly safer than doing manual memory management and raw pointer manipulation in C++. The interesting question is if that's enough for a particular project.
In general, I would argue that it is, because security is but one of the non-functional properties of software and the types of bugs that Rust prevents compared to modern C++ are but one category of security-relevant bugs.
The advantages that modern C++ can bring over Rust would compensate on average for its safety gap.
C on the other hand is simply a losing proposition safety-wise. Whatever I do, the type system won't do much if anything to help me prevent or catch bugs.
> the types of bugs that Rust prevents compared to modern C++ are but one category of security-relevant bugs
Memory safety bugs frequently result in basically the worst possible compromise imaginable: arbitrary remote code execution. It is possible to get RCE in other ways, but lack of memory safety makes it way way easier.
This doesn't change anything, you've just added another link at the end of the system > non-functional > security > code execution security chain.
Each project has the option at every link to decide that they're willing to accept a certain risk there and then tools delivering better results don't matter.
Memory safety is somewhat special because it's foundational: it is a prerequisite for any other sort of safety/security, as memory safety violations often can be(/are) exploited to trigger pretty much any other problem (e.g. RCE can do anything); other security problems are usually more constrained.
The thing is, and Rust advocates seem to consistently plug their ears when they hear it, is that most software written specifically in C++ is very highly specialized stuff with a small specific client set, where security is just not an issue.
According to the poll that JetBrains did when it started working on CLion, about half of C++ usage is in financial software. I will tell you first hand that in most applications in financial software, C++ servers will be talking to other internal servers, exchanges, reputable data distributors, etc. The idea that memory = security risk is just not a connection that people around here generally make.
I also know some game developers and my strong sense is that games are similar. Video games may talk to a specialized multiplayer server, an update server, and that's mostly it.
I could continue, but you get the idea. For most C++ developers I've ever encountered, memory issue == bug, != security risk.
Browsers, which operate on maximally complex data (a Turing complete programming, JS) and are by nature exposed to the entire world, including malicious users who want to harm other browser users, are simply not the typical domain for C++. I think there's every chance that Rust is a good fit for writing browsers, but outside of that things are much less clear (at least, at the moment).
Modern C++ is not as safe as Rust, but it is much safer than C, and significantly safer than doing manual memory management and raw pointer manipulation in C++. The interesting question is if that's enough for a particular project.
In general, I would argue that it is, because security is but one of the non-functional properties of software and the types of bugs that Rust prevents compared to modern C++ are but one category of security-relevant bugs. The advantages that modern C++ can bring over Rust would compensate on average for its safety gap.
C on the other hand is simply a losing proposition safety-wise. Whatever I do, the type system won't do much if anything to help me prevent or catch bugs.