> One could wonder whether that's an issue when IO are fairly short & strongly interspersed with code being run though IMO one of the core observations made by

> One could wonder whether that's an issue when IO are fairly short & strongly interspersed with code being run though IMO one of the core observations made by Dahl and the other Node.js folks was that this is very very rarely the case in modern web applications. Most webapps either a) spend the vast majority of their time waiting on IO, b) have non-IO code very regularly interspersed with IO operations (making event-loop based interleaving based on IO boundaries more useful) or c) both. As a result, Node.js was built with the single-thread/IO-bounded reactor model. I think that this, along with (and perhaps even more than) its choice of language syntax, drove the platform's adoption. It means that code doesn't need to think about thread safety, and that there is only one IO model: asynchronous by default (yes there are exceptions, but they're a minority). That lets users get a lot of scale for free, provided their workloads meet those criteria.