[streety]

Until recently, an ignoring a brief foray into Limbo, I've been a PHP only/focused programmer. I've been working with python more in the past year as I've been doing more work with data processing and statistical analysis for which PHP really doesn't have the tools.

Having said that I wonder if missing the 'beauty' of async I/O etc has more to do with the projects people take than the language. Would a python or ruby developer who focuses on creating web apps have any more familiarity with those concepts than a PHP developer?

[pilif]

because PHP provides practically NO means for async I/O whereas the other languages do.

One of the reasons for this is because PHP was designed to quickly handle single HTTP requests. The scaling is ment to be done on the app-server side and that single request that your script is serving at a given time will take as long as it will take anyways.

So you don't really need the async I/O (in theory).

Python and Javascript (and to some degree ruby) rely on their own web servers implemented in their own language, in many cases with no or bad (GIL) concurrency at which point it gets more interesting to move into an event based model where it becomes imperative that operations don't block.

There async I/O becomes important.

So: PHP: concurrency by firing off another apache/fastcgi process or thread. Don't worry about blocking on I/O.

node.js and some python/ruby frameworks: concurrency by using an event based system. Because one operation blocks the whole server, they need to be quick. async I/O becomes important.

Of course the evented model has huge advantages too: You worry much less about races, you get huge performance with a simple architecture and you can potentially handle much more concurrency (because each thread/process consumes resources that your one evented process does only once).

Both paradigms are interesting, but having first-class functions certainly makes an evented model more convenient to work with.

[barrkel]

Async I/O is important for any time the connection needs to be kept open while processing the request under heavily concurrent conditions; it's less about not blocking on I/O, than it is about avoiding the overhead of context switching in the kernel and the extra resources of keeping a thread / process alive for the duration of the request. I don't see it as less or more important in a PHP context than an event-based model. However, without an automatic CPS transformation (continuation passing style) of the source of your request handling logic - in particular, continuations at the boundary points all I/Os - you do need to write to a pattern which is in effect event-driven.