- Large stdlib that, while inconsistent, frees you from searching packages for everything (vs nodejs).
- I'm sure some will disagree, but php's documentation is top notch, easy to navigate, and with nice completion from user examples (you could say it is a mini-stackoverflow by itself). Golang's docs are good, python's are good but hard to navigate, node's are typically worse.
- PHP's ordered, possibly hash-backed possibly plain arrays are an abomination from a data structures point of view, but god are they handy! Golang is terrible here with its static types (fine) but lack of generics (just check how to sort a list of a non-primitive type).
To this day there is no generic list sorting function in PHP proper.
2. I'd say Python is an easy match in this regard
3. Agreed about the docs - I still find the organisation of Python's docs a bit peculiar.
4. Handy data structures, you say? I think Python might have the edge here.
It's strange you don't mention PHP's biggest strengths: deployment and learning curve: You can begin on almost any commodity hosting with a simple text editor and no knowledge of Unix internals. The amount of extra stuff I had to learn to be productive in Python was huge at the time. It's got a bit better now with various simple deployment options but PHP still wins out for the beginner.
Traditionally, a major pro for PHP was also its broad availability for web space but that doesn't seem to be so important nowadays anymore.
Putting node, python and Go in the same place against PHP is kinda hard as those three are very distinct from each other already ;-)
What many people miss is that very few projects ever cross that threshold.
Kind of like a table saw vs a CAD router.
With php, I have to do stuff like caching responses with apcu to get something similar, but inferior. Which doesn't scale beyond a single server host.
I can serve a lot of requests with apcu, but the curve does drop off at some point.
Both should be able to scale well in a "create a website and return the HTML"-scenario, and it's not unlikely that a PHP setup would be faster.
In a single page app thats mostly based on fetching data from an API nodejs would probably be faster.
About APCu: It's damn fast and very unlikely to slow you down, other stuff will probably bottleneck you way before APCu becomes a problem.
Use PHP as PHP, and nodejs as nodejs.
If you really need async in PHP or want to use PHP somewhat like nodejs then you should probably go for an extension and serve requests directly from PHP. I've had great experiences with that, serving over 500K simple HTTP req/s on a low end server.
But again, if max performance on a single server is so important then you should probably go for a compiled language anyways.
Often the answer is "it depends". Which is usually unsatisfactory for the HN crowd.
I just hate uninformed and unnuanced PHP hating.
There are use cases where it's actually the best answer by a large degree.
It's not that bad anymore. We do have fcgi, fpm, and also user space caches like apcu. You would have to try pretty hard to find a default set up that resulted in process per request these days.
It scales very well on a single host. Which has limits, but limits that exceed some percentile that most projects need. And things like redis take it even further. If you're pushing the limits of php, you probably have a nice-to-have problem tied to lots of incoming revenue. Similar to FB and HHVM.
I agree there's a scaling issue, but nobody is doing process per request anymore. Process pooling is a decade old or more.
I guess the objection to "spinning up a process" is actually a problem with slow PHP initialisation, though? A dinky server can spin up many thousands of processes a second. I'm pretty sure OS process overhead is nothing compared to whatever PHP or Rails or whatever else puts into your critical path, but the language/library/parsing requirements could kill you. (Though people still make this objection to CGI itself, not just PHP...)
Buzzword bingo and all...