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.
I think Rust is annoyingly complex and badly designed (although it has good parts) and this would be the same mistake as past pushs to move projects to C++ because "object orientation is clearly better", and as such also step towards more complexity that is difficult to undo again and therefor actively harmful. The better and more powerful approach to safety is proving correctness, which is already possible today but we lack good opensource tooling. Proofs can be added to existing code without introducing complexity.
Rust and C++'s overcomplex syntax are a nightmare to maintain and set.
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...
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"?