First paragraph as a teaser for those not clicking the link immediately:
> PHP is big. The trolls can proclaim its all-but-certain “death” until the cows come home, but no amount of heckling changes that the Internet runs on PHP. The evidence is overwhelming. What follows is a loosely organised collection of precisely that evidence.
The irony is that the post claims "the Internet runs on PHP. The evidence is overwhelming." and cites companies... that have moved away from PHP. As far as I know, Facebook doesn't use PHP anymore. There also a link to Slack, that migrated to Hack[^1], a language which started as a fork of PHP but is now quite different.
As for the first argument of the page, statistics from W3Tech, the number of PHP sites is mostly a consequence of a few widespread PHP CMS, like Wordpress. It's not a sign that new PHP code is written or even that development in these CMS is still going strong.
In the section "Anecdotes", the reference to "the enormous lead" according to ArsTechnica is junk: ArsTechnica's text is just a comment on the W3Tech report mentioned above, it brings nothing new.
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. In Wikipedia's infrastructure, there are some custom extensions[^2] (compiled plugins for PHP written in C). The right question is not "Can it scale?" but "Is it easy to scale?". In my experience, handling hundreds of concurrent connections (online exams) with Moodle (a PHP Learning CMS) required much more resources than we expected. Laravel can scale, but I guess scale problems would appear much later with some alternatives.
[^1]: https://slack.engineering/hacklang-at-slack-a-better-php/
[^2]: https://upload.wikimedia.org/wikipedia/commons/e/ee/MediaWik...
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.
