| I don't doubt that PHP has some benefits. That said, the reasons cited in the blog post don't seem that unique to PHP. > By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1. Is there a modern web framework where a failed request can crash the entire server? I'm not sure this is a problem in other languages. > Second, concurrency. An individual web request runs in a single PHP thread. Huh, so maybe this could be an interesting concurrency model. But it's not that different than say, Node's promises. The only difference is Node's promises aren't tied to literally making a web request. The restarting the server problem also is not an issue. Almost every mature web stack I've seen has hot reloading. Yes, even in 2016. There are certainly reasons to use PHP, but the trap I see a lot of PHP proponents fall into is assuming that the benefits they see are somehow unique to PHP. Laravel fans love to cite packages, migrations, the ORM, etc. as reasons to use PHP. I certainly think all of these are great features but they're not unique to PHP. |
Erlang/Elixir (or any BEAM language) runs every request in a separate green thread which scales much better than OS threads since most of those green threads can be generously multiplexed on just 4-8 CPU cores due to 90% of the time being spent waiting on a database.
One OS thread per request is such a... strange thing to brag about in 2020.