I agree that trying to eliminate a class of bugs through language design is a good thing to try, absolutely.
I just mean to say that the idea that you inherently make your software more reliable by "rewriting in Rust" is false. I don't contend that it could have benifits but I think to some extent you swap one set of problems for another and maybe in a language you don't understand as well as the one you're coming from.
I have first-hand experience that yes, Rust does make software more reliable. It noticeably changes the class of bugs you deal with. The low-level bugs like memory corruption or dangling pointers disappear. You're left dealing with mainly high-level issues, like features not implemented up to the spec, and deficiencies in the program architecture or algorithms (which you still have in any language).
It's not some Ying/Yang balance of force or a contract with the devil where getting rid of sneaky Undefined Behaviors must be paid for with another evil.
In C I've struggled with multi-threaded software, and even relatively tame solutions like OpenMP ended biting me. OTOH I haven't had to debug a data race in Rust yet (I've caused a bunch of deadlocks, but these are relatively easy). In C, despite my best efforts, I've occasionally had buffer overflows, leaks, and UAFs. In Rust I've had these only when interacting with C libraries via FFI.
You could probably say that my C bugs were my fault, and I'm just not a good C programmer. Well, I haven't got any smarter, but I'm a good Rust programmer.
I just mean to say that the idea that you inherently make your software more reliable by "rewriting in Rust" is false. I don't contend that it could have benifits but I think to some extent you swap one set of problems for another and maybe in a language you don't understand as well as the one you're coming from.