I have the opposite feeling; I am liking Rust more and more and thinking most of the world's C code should be rewritten. It seems like a sweet spot of enforced memory safety, performance, and human/agent readability.
Go should have been the C succesor long ago, at least for 64 bit machines. In the end It's from the same people of Unix/C/Plan9, so they know their flaws and reasons.
For C++ like performance, sadly there's nothing close to Rust, but Zig and Nim can be close and good enough. Inb4 "mah objects", just use Java or C# and forget C++ forever for OOP programming. The sooner, the better. If you like using C++ just as an improved C and hate templates and objects, just use it for QT5/6 and some performing games and applications. Go can handle the rest just fine.
What I'd love is to see projects like Cataclysm DDA:Bright Nights rewritten in Go, they could save tons of issues on compiling (Clang 11 here, a nightmware to compile) and running, because for an open world game using the GC would free tons of waste on references and objects ingame. Also it will compile much faster and it could be ported to most platforms with no efforts at all.
And I say this as an ScummVM user and sometimes I like debugging some old adventure and RPG games under it...
Because I don't think this. A rewrite is cheaper to me.
In that sense, rewriting some code in Rust _may_ be cheaper than fixing the existing code. It may also be more welcoming to newer devs, since Rust can be easier to reason about, which is a long-term investment.
The borrow checker also helps with AI (as long as you don't let the AI use `unsafe`, or completely control what primitives in your codebase are allowed to use unsafe and never vibe-code any of it) — at least, the agent can't stop until `cargo build` passes.
I've also had better experience locally building applications in Rust than in C/C++. `cd ripgrep; cargo install --path .` or `cargo install ripgrep` usually just work, while `make` is usually painful.