3 ms·

Thank you for the very comprehensive answer. You're right - the team sold me on the idea by starting out with a low-latency requirement use case for which most

Thank you for the very comprehensive answer. You're right - the team sold me on the idea by starting out with a low-latency requirement use case for which most of our code base was written in C++. We are almost 50% through with replacing our code base from C++ to Rust. What I can really appreciate are the significant improvements in code execution due to the aforementioned reasons.

ekidd 4y ago
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.
synergy20 4y ago
why is rust 'faster' then c++? I can understand it might be safer, but I think c++ never had a bad reputation for execution speed.
- fakedang 4y ago
  I believe it has to do with garbage collection. C++ garbage collection is a bit of a mess (and that's an understatement although I won't disrespect the language). Rust doesn't use GC as a general measure - memory is freed as variables go out of scope. Also if you want to GC, it has the provision to do so.

ekidd 4y ago

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.

synergy20 4y ago

why is rust 'faster' then c++? I can understand it might be safer, but I think c++ never had a bad reputation for execution speed.

fakedang 4y ago
I believe it has to do with garbage collection. C++ garbage collection is a bit of a mess (and that's an understatement although I won't disrespect the language). Rust doesn't use GC as a general measure - memory is freed as variables go out of scope. Also if you want to GC, it has the provision to do so.