> I don't think there are really numbers that tell us what the vast majority and the tiny minority of applications use. I think most people will have here some personal bias, because they see the applications that they are working on, the applications that their particular industry is working on and think that the rest of world might be similar.

I'm specifically going against my personal bias. I write server-side applications, but most of the code out there is basically apps and such.

> And you already have given GUI as a counter example yourself. More then a tiny majority of applications have a GUI. And all major GUI frameworks are built on top of asynchronous abstractions, because you want GUIs to be reactive (no hanging due to blocking stuff), and because every input port (either from a human input device or from network) can change the shared state and cause output to more than one output device.

If you look at how the users of GUI frameworks write their code, it's mostly synchronous code with some interspersed message-passing type code. The asynchronous nature of GUIs is only really relevant when dealing with button presses and such.

You don't want to have to program all of it as if it's asynchronous. Having to reify the stack manually into a state machine would quickly induce madness for all but the most trivial of GUIs.

Reactive GUIs are pretty simple to do using blocking code: Have a main thread resonsible for the GUI, offload long-lasting work to other threads. Use message passing for communication. Done. You're still programming in a mostly-synchronous model. I think my point stands.

EDIT: Btw, the beauty of this message-passing-mostly-synchronous model is that it doesn't force you to completely change everything in your program around the asynchronous bits. You restrict your asynchrony to where it really matters. That's a big deal for clarity, IMO.