[hashar]

> In the "PHP at scale" section, I don't deny that it's possible to do so, but if Facebook and Slack moved away from PHP, it's probably because programs with other languages scale better.

Facebook was/is mostly dynamic and if I remember properly they had the status cards rendered dynamically via PHP (templating) Wikimedia reparsed the whole articles and included templates on any read requests with variances between parses based on users preferences (for example on Wikipedia you could show links to small articles in green rather than the blue for existing ones and red for absent pages, the size threshold being set by the user), that made the pages un cacheable and required a full reparse.

Facebook had a first pass at transcoding PHP to C++ (hiphop-cpp iirc), eventually they went transforming the PHP AST to bytecode executed in a VM: HHVM. It was back compatible with php 5.x including bugs and sometime poorly designed interface and used WordPress, MediaWiki testing suite to ensure they caught any regressions. The team behind HHVM probably saved Facebook from crippling capex / operating costs and at Wikimedia we literally halved the CPU load when we switched. At the time Facebook and Wikimedia ran PHP 5.3 or 5.4 and both had performance issues or at least concern with the huge amount of CPU required for their workload.

HHVM had some optional language feature on top of PHP such as typing and some helpful additional functions, that became the Hack language which is essentially a fork of the PHP language.

All the work on HHMV and the nice performances from it eventually challenged PHP which with PHP v7 came with a similar VM / Jit system. At that point, the performance benefices of running HHVM vs php v7 where not justifying the extra complexity (notably lack of garbage collector by choice, or complexity in deploying the sqlite bytecode holind the code to be executed). Wikimedia then moved back to PHP.