However, I think the power of PHP is that it is not designed to be its own server, to run forever in the background and handle all kinds of complex async flow. Execution stops when a request is done: no memory and data leaks between requests and easy to reason about.
In practice you don't really need async, except for stuff like sending emails and heavy IO. Laravel simply handles this by pushing jobs on a message queue and handling it via a worker process, but you can use any microservice of course (in particular a simple node app).
I'm no expert either, but I just leave a note regarding Pushpin (http://pushpin.org/) here as an option to have a websocket server together with PHP. It's not a PHP project, but a good tool to have in the toolbox :)
And come on, for "job control" type scripts you should be fired for using PHP over Bash. Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.
Next to no one uses Perl any more. You won't find people to maintain your homegrown stuff - and aside from maintaining an OTRS instance I have not seen Perl code in a decade.
> Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.
Well good luck with Bash if your batch script involves stuff like parsing JSON/XML or interacting with databases. I prefer to write quick one-offs in PHP than wasting hours with Bash scripting; and even if it's no one-off but a script that needs to be run regularly (e.g. via cron), you'll find a competent PHP programmer for maintenance way easier than a competent Bash programmer.
> And come on, for "job control" type scripts you should be fired for using PHP over Bash.
For plain job control, like an initscript, I fully agree with you. But not for anything more complex, for the reasons outlined above.
True, if you run it behind a web server like 99.999% of all users.
If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy.
Still, even on a normal web server, php can do long polling perfectly fine, which is often enough.
> being able to write program flows without dozens of promises is a breeze
It is a breeze with async/await too.
Yeah, I implemented a simple ircd once. Funny days... but I don't know of any library/framework that could help you with the websocket protocol level, and I'm too old for writing my own ;)
But you could use something like websocketd, which spawns a process of your chioce for each client and pipes the websocket to stdin and vice versa.
https://github.com/joewalnes/websocketd
Each PHP process looks like it takes about 5 MB of ram on my laptop, so probably not the best method for 5000+ concurrent users if you use PHP, but still.
FYI - http://socketo.me/
[Maybe it was just a joke and I did not get it... or I did get it but did not identify it as a joke... however... I would like to see some beef...]
PHP is in any case a better choice, performance-wise, than Python or, god forbid, Java.
All just to make PHP a little faster. I think you are making my case.
Many websites don't ever get to 350M users, so it's safe to say that plain PHP will satisfy your startup for a long time. Also, PHP7 is pretty much on par with HHVM in real-world scenarios: https://kinsta.com/blog/the-definitive-php-7-final-version-h...
There might be a better way but I'd effectively added support for server push from our PHP app in a morning, with great results.
The other thing it provided me was clear evidence of the "best tool for the job" in a shop that demanded PHP.
The problem I have with PHP is what is usually touted as it's benefit. It's easy to find PHP developers. The problem: most of them are not very good.
To close, there are many more PHP RFCs that internals should approve, e.g arrow lambdas with automatic variable closure, design by contract, etc. These could really bring the language into it's own.
1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses
2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server
3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherwise
PHP on the other hand has other use cases:
1) stuff that needs to be massively and easily deployed - you can grab PHP/MySQL/Apache hosting everywhere for either dead cheap or totally free. Examples include Wordpress, Drupal and MediaWiki
2) stuff that is highly complex in its flow. If your API requires dozens of DB calls, filesystem access, networking or just involves thousands of SLOC, you're better off writing it in PHP as it (since PHP5) carries a solid OOP stack - and even if you're not writing OOP code, being able to write program flows without dozens of promises is a breeze.
3) stuff that requires weird extensions to PHP. Basically there are bindings for everything and it's trivial to write your own binding to a library if it does not exist yet. For example, I have used PC/SC to interface with crypto smartcards, and it works surprisingly well.
4) shell scripts. PHP interpreters are widespread - OS X includes PHP by default and it's a $package_manager install php away on most Linux distributions. Perl and bash have their own strengths but honestly, Perl is outdated and PHP abstracts a load of stuff away, so you can write shellscripts that work on all major platforms without having to account for stuff like "does the OS have GNU grep, busybox grep or BSD grep".