It is, and Hack exists ONLY because PHP was not cutting it for a big project like facebook. Its the biggest example out there why should not use PHP for anything close to, say 10% of facebook scale.
I doubt anyone here is working to 1% of fb scale, let alone 10%.
The answer to "why Hack" needs to be viewed in the historical context of "when Hack" and what was happening (or not) in the php ecosystem at that time.
Things have changed a lot since, in terms of performance, language longevity, ecosystem etc. Its a perfectly reasonable language to adopt for many orgs.
Seems to line up with what the authors say:
At Facebook scale — with thousands of engineers shipping new code twice a day — slowdowns like these are even more problematic.
https://engineering.fb.com/2014/03/20/developer-tools/hack-a-new-programming-language-for-hhvm/
> Its the biggest example out there why should not use PHP for anything close to, say 10% of facebook scale.
What a weird take to base your current belief on something that happened more than a decade ago.
Not only the condition for Hack creation (speed, memory usage and strict type checking) have been fixed a long time ago since php 7.0
But also if you reach 10% of facebook scale, it doesn't matter what language you used, you will need to rewrite anyway.
Show me a company where PHP is the issue because they reached 10% of facebook scale, and what you're showing is a company that succeeded thanks to PHP. Applies to other language the same. Picking your stack based on "but what if I reach that scale" has to be the mother of all premature optimisations.