I thought they tried it multiple times. The problem is they had so many developers writing new code any rewrite attempt would fall behind super quickly?

So they created their own language Hack so allow a slow transfer from PHP to Hack. Which is basically the idea behind Kotlin.

Was there a separate initiative for assembly, or are you thinking about HipHop? HipHop was for C++ and got a lot of attention back when it was released.

Yes, the 2nd rewrite for a VM, where the JIT compiler turned out to be quite good versus HipHop, and development focus switched to HHVM.

I was thinking about HHVM, which I believed was essentially assembly for a VM. Am I wrong on that?

No, you're right. HHVM was the 2nd iteration. I was thinking of the first project, which was for C++. Looking at wikipedia, that was called HPHPc.

I know you're being hyperbolic, but during my time there, your impact was measured only on measurable things like performance gains but never on lines of code. So engineers would always go in the direction of whatever gets you the biggest win.

Sometimes that actually meant rewriting the thing from scratch, and other times that meant adding something else as a middleware to prevent touching the original thing.

For the most public success story, React was a complete rewrite of the thing before it, for example.

I spent five years there, and made that joke constantly.

It's mostly hyperbole but there's definitely a kernel of truth to it. I generally dislike rewrites and I wonder if FBs approach influenced me more than I realized at the time.

Rewriting in hip-tech-du-jour is for startups with lots of funding and little of traction.

Why would a massively successful company toss a stick in their own spokes by tearing the product to ground?

But it's actually a _really bad_ strategy for a startup! It'll be realized the moment you try to hire for hip-tech-du-jour. Most likely, you don't even have the problem that hip-tech-du-jour claims to solve.

TIL what hip-tech-du-jour is lol

Every company should go to ridiculous lengths to avoid rewrites. Rewrites of significant tech (as a proxy, lets say 100+ kloc) spell doom. Doom.

Every company? What about banks that have old codebases running on Cobol?

I'm also very skeptical about big bang rewrites, but there are points where you need to migrate off certain tech. Ideally you can make that transition piece by piece though, but that also introduces its own set of problems (now you have two systems and the new one has to inherit some of the baggage of the old one in order to be compatible).

This is exactly the kind of innovation I see coming out this current AI boom we're in. Take legacy codebases and spit out complete rewritten versions in whatever language that not just translates, but takes it much further and re-interprets it on top of modern architecture designs. It completes it with tests and a basic UI, or whatever makes sense for the project.

Those systems are well understood and well tested, so it's not cost effective at the moment to embark on a complete rewrite. Current AI coding systems are also very unreliable, so it's just a matter of time before those two meet on the graph and voila, another boom in moving the legacy world into safe languages.

It’s definitely not for the timid or mediocre

I remember when I used to rewrite stuff before fully understanding the drawbacks of what I was rewriting it in.