← Back to context

Comment by surajrmal

1 day ago

It depends. I migrated a 20k loc c++ project to rust via AI recently and I would say it did so pretty well. There is no unsafe or raw pointer usage. It did add Rc<RefCell in a bunch of places to make things happy, but that ultimately caught some real bugs in the original code. Refactoring it to avoid shared memory (and the need for Rc<RefCell<>> wasn't very difficult, but keeping the code structure identical at first allowed us to continue to work on the c++ code while the rust port was ongoing and keep the rust port aligned without needing to implement the features twice.

I would say modern c++ written by someone already familiar with rust will probably be structured in a way that's extremely easy to port because you end up modeling the borrow checker in your brain.

> I would say modern c++ written by someone already familiar with rust will probably be structured in a way that's extremely easy to port because you end up modeling the borrow checker in your brain.

I can't stress out how much important this sentence is. I would even remove the "familiar with rust" part.

Anyone who still thinks it's good to use C/CPP on modern hardware where Rust support is available and good: please print the sentence above and post it all over your place.

  • The reason folks still use c/c++ is because of ecosystem. Chances are you have a lot of code you depend on and don't have straightforward ways to port it (and all the transitive deps). Especially in the case of larger enterprise software where there are 10s of millions of lines keeping you entrenched. Foundational things like your threading model, async executor, etc can make it difficult. If you're operating in a micro service environment and your core does are both minimal and ported, the journey becomes much more tractable.

    • I assumed new projects but I just realised that I didn’t write it.

      But still disagree: we have cbindgen.