I think you're right, but I also think that you're missing the point of the GP's argument.
Most people aren't building WhatsApp, they're building a CRUD app. And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects. Compare this to a NodeJS server that fully terminates when one request causes an uncaught exception and you'll see that PHP and Erlang have more in common, philosophically, than people like to admit.
So the way I read the GP is that despite its many safety guarantees, Erlang never got popular because PHP offers the most important of these guarantees in a more accessible way.
In fact, I know of no language that offers better crash resilience and isolation than PHP. I can run 100 shared hosting customers' shitty PHP code on a single Apache server and they'll have a seriously hard time making their bugs impact other customers. Try that with Erlang :-)
Hmmm.. Interesting. On the last point I disagree unless you are launching php process per request then you'll have to set mod_php or php_fpm recycling ridiculous high to cope with 100 customers and their shitty PHP code (or the shitty PHP code from the top 10 one-click solutions installed) leaking memory everywhere. On the isolation side the industry answer to this is nasty prop solutions like CloudLinux and other custom solutions where each customer essentially has a request pool (e.g 5 php-fpm waiting around under the uid of the user) - counter to most shitty PHP web hosting providers goal of density, 'lets keep this server lightly loaded for the highend packages - just put 5,000 account on it okay'. Typical PHP hosting is not pretty, they're about 10 years behind the times, cough cpanel.
"And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects."
Exactly my point, thank you for clarifying. PHP crashes (in some form or another) all the time, but the application can still remain up because that PHP process only has state for the one request (kind of like a single erlang process having state for only one request).
Most people aren't building WhatsApp, they're building a CRUD app. And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects. Compare this to a NodeJS server that fully terminates when one request causes an uncaught exception and you'll see that PHP and Erlang have more in common, philosophically, than people like to admit.
So the way I read the GP is that despite its many safety guarantees, Erlang never got popular because PHP offers the most important of these guarantees in a more accessible way.
In fact, I know of no language that offers better crash resilience and isolation than PHP. I can run 100 shared hosting customers' shitty PHP code on a single Apache server and they'll have a seriously hard time making their bugs impact other customers. Try that with Erlang :-)