Memory bugs are unknown unknowns that AI may or may not catch. There's net-present-value in switching to a language where certain types of memory bugs are impossible.
On the contrary, AI agents are doing an outstanding job of catching and fixing them. The jury's still out on the cost-to-value ratio of improving existing code vs. rewriting it.
I think Rust (the compiler / borrow checker) kinda finds bugs for you, some of which C/C++ does not.
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.
I guess ask the bun people why they translated from zig to rust. I think it was essentially because rust guarantees a set of bugs can't exist so over medium to long term timeframes you end up with less technical debt.
Because making segfaults impossible is simply a better solution to playing a game of whack a mole of "crash, root cause, fix and add test for that very specific bug"?