> PHP has so many hidden benefits:
> - it's stateless by design (much easier to scale)
I'll grant you this one. Though PHP in practice goes to great lengths to add state back in for performance reasons (e.g. memcached, or for a while APC).
And Haskell is stateless, too, yet not a frequent choice for web work.
> - it was "serverless" before Serverless
This is retconning. It was never trivial to set up a LAMP stack, especially at scale. I can't tell you how many times I've seen the PHP "too many open database connections" error because someone just treated their Wordpress blog as "serverless" and it went to the top of HN.
> - surprisingly performant
I can't speak about the latest stuff, but PHP5 in ~2014-15 was abominably slow. There were certain "benchmarks" which indicated it was fast, but on closer inspection, these were simply calls where PHP provided thin wrappers around C calls.
I had to once take an Excel file, parse it and then present certain fields to the user for the DB to be updated. This was possible in PHP, but it took excruciatingly long (like 8 minutes - in fact, sometimes Apache would just drop the connection), and third party library support was just awful. I implemented the same task in Python, and not only was the code much simpler and and easier to write, but the task took a second or two each time.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
The standard library is a toxic sludge of surprises. Nothing is consistent. "Will this function treat an array like a list or a dict? Who knows?"
Maybe this is better now, but the last time I dabbled in PHP, I spent a while trying to get a workable debugger set up and gave up. Stepping through code is apparently impossible, and every now and then you hit some fatal error that immediately crashes your code.
> - deployment is so simple, just drop a file on a web server. No middleware needed.
What does this mean?
First, PHP has middleware (e.g. memcached, Apache/Nginx).
Second, the complexity of deploying a Python, Node, Rust, Go or Ruby application is not the "middleware." The complexity is ensuring that the update is correct, the update is applied consistently, can be rolled back, doesn't cause downtime, etc. I could also do updates by running webpack dev server in prod and dropping files in there for deployment. As easy as PHP, yet a terrible idea.
> - No long compile times because there is no compiling needed.
This is odd to say the least. PHP's biggest weakness IMO is that each thread must entirely parse and interpret its executing program on every single call. That is a ton of wasted work, and there are literally sections in the PHP docs about tools to circumvent this problem.[0] And the solutions involve caching, which mean we give up (1) the "stateless" benefit and (2) the "just drop in a file" benefit, or else we need to add a bunch of cache coherence logic. It would be so much easier if someone could compile the PHP code to a bytecode format and drop _that_ in, which could just start executing on an interpreter ASAP.
Ultimately, I think the list is getting downvoted because it deviates so much from developers' experience with PHP. PHP started out as a sub-Turing templating tool that had a Perlish language bolted on, which then mutated to look a lot like Java. Eevee's classic blog rant[1] calls it a "fractal of bad design," but the reality is PHP has no design: it's just a kludge of duct tape and bolts.
Also, maybe this is totally incorrect now with PHP6--er PHP7 and PHP8. But my experience with PHP4 and PHP5 was so horrific that I will not be working with it again. I've yet to find a PHP use case that is not better solved with a combination of a static site generator and something like AWS Lambdas or Cloudflare Workers.
[0] https://www.php.net/manual/en/book.opcache.php
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/