Richard Bucker

Rewrite in Rust, Really?

Posted at — Sep 19, 2022

NO, no, no. Actually Maybe.

rewrite for speed, no

This particular incentive, has been around for years. People used to write a lot of code in Java because it was correct and because of the language design could/would make sloppy code and reasoning about certain class/structures easier and safe. And before the JIT people complained endlessly about Java’s performance and there were an endless number of projects that were rewritten in C or C++ strictly for performance reasons. At the time that made plenty of sense but not any more.

low code, no code

Now we are in a completely different universe. We are still experiencing a weird workplace. Every response to the question “I need more hardware” should always be responded to with… not for 10 new users. But really, take any quasi large codebase of 5-10 millions of lines of code and reasoning about it and making whatever paradigms in one language work in another with having to “work around” things… You will lose so much.

… and it’s faster.

I’ve worked on a number of rewrites and they all fail because there are always side effects that are never taken into consideration. I rewrote OS/2 presentation manager from 16-bit to 32-bit for IBM Workplace OS. It was non-trivial… a forgotten fact was that the OS/2 development team would drop a new code tree on my about every 2 weeks… VCS was terrible in those days. I do not recall how many LOC of C but there was about 2M LOC of Assembler. Talk about side effects in the processor?

Hardware scaling still works

Every so often they talk about Moore’s Law falling down. Maybe it will but it’s not that big of a deal. First of all there are so many ways to solve this problem. Scale is not scale but actually magnification. You get as much work as you can done then federate along some dimension that makes sense. There should never be a single view of all things. That’s not how the search engines work.

Conclusion.

Forget the rewrite.