>These three things turn out to be among the most important parts of a server-side language
So the language does two of these three things by not doing them at all ?
State: oh there's no state across requests.
Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.
> PHP gets them very, very right. The rightness was accidental.
Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".
Nobody's asking you to like PHP. I'm explaining why it's effective; if you'd like to build something better, there are affirmative lessons to learn from PHP's undeniable successes. While your point about Erlang is correct for pure PHP, one of the nice things about the "curl as concurrency model" world is that the thing on the other end of the curl doesn't have to be PHP, or stateless.
Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.
Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.
The point is that it's still shared state, so it's possible in practice to take down your server if you manage to corrupt your database or a file on your filesystem.
About the only thing you're protected against is memory leaks, and that seems to be because you have to, otherwise PHP would fall over in a big heap: https://www.google.com/search?q=php+memory+leak
I haven't had any problems with memory leaks running things like Django or Bottle.
So the language does two of these three things by not doing them at all ? State: oh there's no state across requests. Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.
> If you want to run some code in parallel, Why do you even bring up parallelism in a post about concurrency ? ( http://news.ycombinator.com/item?id=3837147 )
> PHP gets them very, very right. The rightness was accidental.
Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".