There was a long time to catch up, yes. But HHVM did several big improvements to their JIT tech between then and now.

PHP7 also rolled out with very little noise about stability, migration issues, etc.

Not knocking FB at all, just noting the PHP folks did a nice job.

The PHP team is absolutely obsessed with backward compatibility. They broke surprisingly few things with PHP 7, and everything they broke was clearly documented.

You don't get to power a significant fraction of the world's most important websites if you break backward compatibility every few months.

They broke an unusual number of things in 7.1, a couple somewhat annoying e.g. defaulting DateTime('now') to including microseconds, without a single builtin function available that can strip/change microseconds on a datetime.

Yes, but they decided to keep it to 7.1, not 7.0, which meant the majority of the perf upgrades were available to most users who migrated to 7.0 _easily_.

7.1 was where all the breaking changes got pushed as a result.

PHP in itself perhaps but I have seen major efforts being put into 5.3 -> 5.6 and 5.6 -> 7.x.

One thing that broke badly was phpunit and related libs for mocking etc.

This was a very vanilla PHP project by the way, no frameworks etc.

FWIW, I had to deal with HHVM a year ago, when PHP7 was recently released, and while PHP7 was already quite stable, HHVM (and especially Hack) was misbehaving in seemingly common situations.

I had a similar experience to this.

I think the difference is that FB was really focused on making sure HHVM ran for their internal use cases specifically, and broad compatibility was a secondary concern in the early days (and perhaps still is? I haven't looked at HHVM in a while).

To be fair, they were quite transparent about this, and published quite a bit of documentation around what worked and what didn't work when running PHP on HHVM so that was good.