Note that the difference vanishes when the language allows for closures. With closures, you can write code that looks like "one thread per request", but could i

Note that the difference vanishes when the language allows for closures. With closures, you can write code that looks like "one thread per request", but could in fact be using asynchronous I/O: wait_for_response(request, function(response) { do_something_with_response(response) ... }) This becomes even more clear in Ruby syntax, where you don't have to nest the reply handler into the wait_xxx function: wait_for_response(request) { |response| do_something_with_response(response) ... } Using monads, you can even abstract the difference away completely. That way, the code looks like ordinary imperative stuff: response <- wait_for_response(request); do_something_with_response(response) If your language provides continuations, you can even handle multiple responses that way. Paul Graham did that in Viaweb (http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt, section "Closures Simulate Subroutines"). tl;dr: The asynchronous I/O is only hard to use in languages which lack essential features. In modern languages you can write "intuitive" code that works for both cases, and you are free to switch from multithreaded sync I/O to asynchronous I/O as you like.