> Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite.
I worked for a startup that stopped feature development and did a complete rewrite of a huge codebase. I was assigned to a side project during this time and missed the entire rewrite process. I came back to a completely rewritten codebase.
There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.
If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch.
I think they did it the right way based on my pre-LLM. Rewriting into a different language as fast and basically as possible is important for getting the team switched over quickly. Rewriting into a different language in X days is actually a good goal to minimize.
> There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.
> If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch
They eventually might regret this, when they are trying to get rid of the last lines of unsafe code. Rust needs to be written differently before you can write safe things to perform fast when compared to other languages or unsafe code. It takes a lot of experience before you can see it.
I doubt it.
If this were a major issue then you'd have to always nail your Rust architecture correctly from day 1 to handle future unknowns, and this isn't the case.
More importantly, LLMs are more than capable of figuring out how to rearchitect code and they have no problem making sweeping refactors for you, especially throwaway experimental ones that were way too expensive to do not long ago.