> Also, a good lesson from Facebook: instead of rewriting their PHP codebase, they extended the language by creating the "PHP++" language Hack (along with the HHVM runtime), and incrementally changed their codebase to take advantage of Hack
I agree with most of your comment, but I don’t think this part generalizes. This isn’t feasible for most companies unless you’re operating at Facebook scale.
I agree it doesn't generalize, but I don't agree that it's because of "scale". It doesn't generalize because not every company should write its own language (and can't hire good enough engineers for this). And, fortunately, most "legacy" codebases aren't in "bad" languages, so there's no need for this.
Afaik, the team that did Hack/HHVM at Facebook is ~5 people. I don't think you need scale for this (the rewrite of the code itself is not a scale thing, the codebase is usually linear-ish in the number of engineers).
My point is: instead of doing a rewrite, be inventive and avoid it, and this is a great example.
And this made sense for Facebook because it probably would've taken 100s of engineers to rewrite all their php.
Also, not every company could hire the 5 people needed to do their own version of a hack/hhvm project. But at some point it makes sense to find those people instead of rewriting in an unrelated language
It’s not about how many engineers it takes to make a new programming language or runtime.
Facebook has the scale to invest in creating tooling, IDE extensions, core libraries, documentation, training, test frameworks, bindings, etc for a new language that they create. They also have the organizational scale and career development to make it worthwhile for an engineer to learn their proprietary language.
I agree with most of your comment, but I don’t think this part generalizes. This isn’t feasible for most companies unless you’re operating at Facebook scale.