As someone with over a decade of professional C++ experience, here are some things your company might experience during this migration:
- A dramatic reduction in runtime crashes, and a ~70% reduction in security vulnerabilities (based on Microsoft's analysis of security bugs, but also personal fuzz-testing experience).
- Much better out-of-the-box tooling. You can set up cargo, VS Code and rust-analyzer in 5 minutes. "Maintaining the build system" will typically become a thing of the past. Rust also provides many verification features for free that would require setting up static analyzers for C++.
- A much easier time integrating third-party libraries. But you may loose access to certain domain-specific libraries, depending on your problem domain.
- Safer use of complex threading and/or async, if you need them for performance. Look at the Mozilla experience converting complex concurrent C++ modules to Rust. They've written a lot about it and it has almost always been a giant win.
- Hiring is a tradeoff: Depending on where your company is located, you may have more local C++ programmers. But if you do remote hiring, the Rust talent pool can be fantastic.
- It's easier to train people from scratch. Rust is not a small language, but it's a lot smaller than knowing the entire history of C++ gotchas and idioms. Also, Rust provides much better guardrails for novice Rust developers. It's feasible to take a strong junior developer, train 'em up, and turn 'em loose.
A migration like the one you describe makes the most sense if 3 things are true:
1. Your C++ codebase is small enough to incrementally rewrite (and your team knows how to manage an incremental rewrite without too much loss of velocity).
2. Your problem domain does not rely on major C++ libraries with no Rust equivalents.
3. Your developers are enthusiastic about Rust.
If any of those three factors were missing, however, then I would normally advise against a rewrite.
- A dramatic reduction in runtime crashes, and a ~70% reduction in security vulnerabilities (based on Microsoft's analysis of security bugs, but also personal fuzz-testing experience).
- Much better out-of-the-box tooling. You can set up cargo, VS Code and rust-analyzer in 5 minutes. "Maintaining the build system" will typically become a thing of the past. Rust also provides many verification features for free that would require setting up static analyzers for C++.
- A much easier time integrating third-party libraries. But you may loose access to certain domain-specific libraries, depending on your problem domain.
- Safer use of complex threading and/or async, if you need them for performance. Look at the Mozilla experience converting complex concurrent C++ modules to Rust. They've written a lot about it and it has almost always been a giant win.
- Hiring is a tradeoff: Depending on where your company is located, you may have more local C++ programmers. But if you do remote hiring, the Rust talent pool can be fantastic.
- It's easier to train people from scratch. Rust is not a small language, but it's a lot smaller than knowing the entire history of C++ gotchas and idioms. Also, Rust provides much better guardrails for novice Rust developers. It's feasible to take a strong junior developer, train 'em up, and turn 'em loose.
A migration like the one you describe makes the most sense if 3 things are true:
1. Your C++ codebase is small enough to incrementally rewrite (and your team knows how to manage an incremental rewrite without too much loss of velocity).
2. Your problem domain does not rely on major C++ libraries with no Rust equivalents.
3. Your developers are enthusiastic about Rust.
If any of those three factors were missing, however, then I would normally advise against a rewrite.