[zhong-j-yu]

I apologize for the sensational and generalizing title. What I'm talking about is focused on web applications, and from empirical data, it seems that most web servers handle very few concurrent requests, therefore it would be silly to go all async to avoid threads.

I'm very surprised that many people here argue that async code is much better to understand than sync code. Ok, so that part is subjective, and let's file it under personal preference. For people who love synchronous coding but fear the cost of threads, I'm trying to make an argument that the fear is probably not justified.

[deadgrey19]

Thanks for the very considered response. I'm pretty interested in this because some of my recent work has been about designing I/O APIs/abstractions.

My reaction is due to my experience which is that threaded programming is something that's very hard to get right and especially to maintain. Async programming cleans up the threading and makes it kind of implicitly cooperative.

I was involved in a big move of some core infrastructure from a multi-threaded design over to a pipeline of async style apps. The result was a huge boost in productivity and debugability which worked out really well for the company.

[fleitz]

'What I'm talking about is focused on web applications, and from empirical data, it seems that most web servers handle very few concurrent requests, therefore it would be silly to go all async to avoid threads.'

It might be an idea to look at this 'empirical' data and figure out which webservers use forking/threads and which use events/async, then you may realize why the high concurrency webservers took the 'silly' route of avoiding threads.