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 u

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 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.