It's interesting to see this, and curious if you look at it from an organizational decision making standpoint. Hypothetically, because I'm not involved in any o

It's interesting to see this, and curious if you look at it from an organizational decision making standpoint. Hypothetically, because I'm not involved in any of this, but still: Facebook was initially implemented using PHP, and you can read this process as continued iteration based on this very early decision. From the outside, Facebook seems to have always taken what they had, taken the problems they currently had, and made the most incremental change they could to fix whatever problem they had. From PHP to HHVM to Hack to dropping PHP support, they continued iterating on what code base and development chain they currently had. If you take a step back though, Facebook is gradually moving to a different programming environment, from a dynamic language with very loose semantics to a statically typed system with (from code I've seen in e.g. phabricator) a very different programming style than run of the mill PHP. While iterating incrementally, they still ended up forking PHP and moving to a different language. The approach is quite different from e.g. Twitter though, who started off using Ruby on Rails, and then moved everything to an entirely different tool chain (Scala) when they found Rails couldn't hold up with their problem set. This difference in approaches isn't quite the same as the good old "rewrite vs refactor" dichotomy. Twitter's change was certainly incremental too, moving individual services to Scala bit by bit, setting them live incrementally instead of a "big bang" rewrite where everything moves to Scala one day. I think the main difference is planning horizon: do you opportunistically fix whatever is broken right now, or do you make a long term plan on what you want your future platform to be, and then set out to get there? Opportunistic fixing has the advantage that you can be pretty certain you're fixing the right problem, and don't invest in YAGNI features. On the other hand, you risk ending up in local optima. Pouring a lot of effort into PHP makes sense if you plan to continue using it - but if you end up forking the language anyway, you loose a lot of the advantages of a shared ecosystem (and arguably damage the existing ecosystem in the process through fragmentation). You could equally well imagine Facebook picking a different future tech stack five years ago, be it Rust or Go or whatever, and add the features they miss from PHP to it. I think it's an interesting thought experiment where that'd have taken them. I have no idea if taking that path would have been better for any of {Facebook, PHP, target language X, world}.