> Node didn't make async IO fashionable As far as I can tell, Node made it fashionable to use the async programming model for the entire application in server

> Node didn't make async IO fashionable As far as I can tell, Node made it fashionable to use the async programming model for the entire application in server code. I'm sure it was done before, but not nearly as commonly, especially not to the point that people, like the commenter I originally replied to, consider it a prerequisite to "permit the interleaving of fast and slow activities", even for scientific computing. > Synchronous IO was slow, Not fundamentally though, but because of implementation details like bad thread scheduling algorithms. > memory-inefficient (to spawn multiple threads), and didn't scale well Yes, and I explicitly acknowledged that in my original comment. But it's efficient and scalable enough for most applications (which don't have millions of users) and is still very widely used, and people have found ways to make it more memory efficient as well. > Event loops in net servers were mostly popularized by nginx [2] to explicitly solve the C10K problem, which is what started driving folks to use event-loop async programming. SO nginx came out in 2004, node in 2009. Did the 5 years in between really see a lot of people writing asynchronous application code? In what language? It's quite possible that that was a development I missed at the time. > Moreover event loops had been popular for years in GUI programming before multiple cores simply because CPU-level parallelism just _was not possible_ (well except for ILP which is a bit different). For example, Tcl/Tk had an event loop driving GUI display logic for ages [3], which really is the same problem. Instead of waiting on NIC events, we were waiting on keyboard/mouse events instead. Yes, event loops are the standard in GUI programming almost everywhere. Java Swing did that too - but with an otherwise entirely synchronous multithreaded programming model. But the reason for that is most definitely not that "CPU-level parallelism just was not possible", nor has it anything to do with "waiting on events" necessitating an event loop as your entire programming model. The reason is that multithreaded GUI toolkits have been repeatedly tried (all the way back to Xerox PARC, long before multicore hardware) and found to lead to insurmountable issues with deadlocks: https://web.archive.org/web/20160402195655/https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-toolkits-failed-dream https://web.archive.org/web/20160402195655/https://community...