The original implementation is 20 years old. Some very good people designed it, but it's from the era when computers came with one CPU and GPUs didn't do much.

C++ programs tend to be heavily inheritance oriented, with huge lists of includes and inheritance. Decoupling things to parallelize them is very difficult in that environment. Rust is mostly a single assignment language with move semantics, which encourages creating objects (yeah, the Rust crowd calls them structs) and passing them off to something else in a somewhat functional style. So you get programs that are less tightly coupled. That's useful if you find you want to pass an object to another thread, put it on a queue, etc. for performance reasons.

Any dangling pointers or cross-thread references will be caught at compile time. That alone makes development far easier.

Although not perfect, assuming all source code is available, clang and visual c++ checkers can do similar checks.

So it is always a matter of equating the value of a full rewrite and how well the checkers are able to provide valuable feedback.

Which I concede Rust will be much better, however then there is the whole loss of ecosystem to also consider.

> clang and visual c++ checkers can do similar checks.

> Which I concede Rust will be much better,

Aren't these two statements contradicting each other?