[curiousDog]

Seems like you're looking at it solely from a web server/application back-end perspective. Async I/O and the corollary, freeing up threads, is useful in lots of other places like UI or applications that require very low latencies (We had a distributed process that had to respond to heart-beat requests from other machines amongst other I/O bound requests. Tying up threads when doing I/O would've been a death sentence).

[zhong-j-yu]

UI - of course the UI thread should not be blocked in handling IOs. My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code.

heart-beat - yes we'll need concurrent threads for handling concurrent requests in the blocking world; the question is whether this will result in too many threads, which depends on the application.

[MaulingMonkey]

"My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code."

Sure. But how do you handle that? IO results need to be communicated back to the UI thread somehow.

Throwing together a whole new thread+stack against a named method that communicates back via explicit messages (or however you want to get the results of IO back to the UI thread) seems like a bit much if all you want to do is download a motd.txt and stuff it in a label.

[zhong-j-yu]

There is no problem to modify UI state from any thread; just put up some synchronizations.

The hard part is, if the modifications do not form a single, predictable, serialized chain, how can the programmer reason about them? This problem is independent of async/sync. If you use C# async for a UI action, you still need to worry about it.

[MaulingMonkey]

> There is no problem to modify UI state from any thread;

Some UI APIs aren't thread safe and can't reasonably be made thread safe. They may even be kind enough to check the calling thread and intentionally throw exceptions (or otherwise abort) if invoked from a non-UI thread.

Hilariously, I've had to work around race conditions in such an API. Just because my access was forced to be on one thread, doesn't mean it's implementation was!

> The hard part is, if the modifications do not form a single, predictable, serialized chain, how can the programmer reason about them?"

Reusable async patterns can help you knock off the "single" and "serialized" bits of the microcosm you care about, leaving you to grapple with only the "predictable" one without the pointless "easy" boilerplate distracting you with additional complexity, line count, and bugs.

> If you use C# async for a UI action, you still need to worry about it.

Agreed. If you just spam the async and await keywords without understanding what you're doing, you're not magically going to get the benefits of a single, serialized chain of events. And they're not going to turn the inherently unpredictable response timings and contents of a series of web queries into a predictable one.

[kaoD]

> There is no problem to modify UI state from any thread; just put up some synchronizations.

It reminded me of the "I know, I'll use regular expressions" joke.

[zhong-j-yu]

The single-event-thread design is not without its own problem; programmers have difficulty in understanding and abiding to it too.

Here we have an inherently concurrent problem - user actions and some IO actions occur concurrently. That problem cannot be reduced by some API or language trick.

[kaoD]

> The single-event-thread design is not without its own problem; programmers have difficulty in understanding and abiding to it too.

Definitely not my experience. jQuery is very popular among unskilled programmers because its async model is very easy to understand. I use it to teach async!

> That problem cannot be reduced by some API or language trick.

Why? Reducing problem by API or language tricks is exactly what abstraction is for.

[fleitz]

Given the Universal Turning Machine and the Church-Turing thesis in actuality all of programming except for assembler is pretty much some API or language trick.