I’m not arguing that we should rewrite everything in rust. C and C++ are fine languages. But sometimes it really is better to just have your code in a different language rather than deal with FFI. For example, I have some collaborative text editing code in rust and recently I just ported the whole thing to typescript, because it’s just straight out easier to use in a browser that way, compared to dealing with a wasm bundle.
I think the big mistake people make when rewriting into a different language is doing a refactor at the same time. This is the wrong way to go about it. First port directly the code you have. Then port your tests and get them passing in the new language. Then refactor. Obviously there’s always some language differences - but ideally you can confine differences within modules, and keep most of the module boundaries intact through the rewrite. You can also refactor before translating your code. If I were porting something to rust that wouldn’t pass the borrow checker, this is probably what I’d do. First refactor everything to make the borrow checker happy - so for example, make sure your structs / classes are in a strict tree. Then get tests passing. Translate between languages and cleanup.
If you approach it like that, rewriting code is a largely mechanical process. It really takes a lot less time than people think to translate code, since you don’t actually have to understand every single line to do it correctly. So the time taken scales based on the number of lines of code. Not the number of hours it took to write! And then, if you want to refactor your new program at the end, go for it.
Going from Rust to TypeScript will normally be pretty easy—though if things like numeric and bytewise manipulations are involved, it can be tough. Going from TypeScript to Rust will often be easy, but also often be fiendishly difficult to do without refactoring a lot, due to ownership model differences.
Occasionally I’ve chosen to do a refactoring in the source language first, and then port that. That can work decently, though it depends so much on exactly what the changes are and why they are, which is often to do with which two languages are involved.
The best days I ported maybe 1500 lines. On the "worst" days I did 0 lines. In all, 500 lines a day feels like the right ballpark for this sort of work.
Kill it with fire.
If rust avoids defects due to programmer mistakes, then throwing a shitty programmer at it is functionally safe (or safer than otherwise) because their shitty code won’t compile. So worst case is they don’t do any harm, and best case is free cheap labor
But assuming you're experienced with Rust, porting something is actually both easy and enjoyable.
Porting something as your first Rust project is going to end up like a dirty hybrid.
It's an excellent learning opportunity, but it will not leave a good showcase of Rust.
