I hope someday better language / library / tooling support (not necessarily limited to what was announced yesterday ...) can make async code a routine thing that you just routinely apply to any I/O or long-running code, rather than only doing so with trepidation ...

@magicalclick: If you mean multithreaded code, then yes, it's easy to overuse. If the computer only has 2 cores, splitting your application up into 80 threads is actually going to slow it down, since more time is spent switching between threads than actually doing work. But in general, it's a good thing.

Oh yeah, I am talking about multi-threading in general. Didn't thought about the async library.

What I mean is, multi-threading not only may slow down performance, but, the organization of code. I mean, in the worst case, all method calls are async. Meaning, for every method that returns, it returns an method complete event instead of the normal call stack.

Imagine instead of say, functionM call methodA then mothod B, You do, register modthod B to eventhandler of methodA_complete_event. Then, functionMcalls methodA asynchronously. And you do it for every single mothod calls.

That would be the extreme async coding.

Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.

There's overhead to setting up asynchronous code to execute so you should analyze your performance and scaleability bottlenecks before you implement such code. The new async/await syntax mitigates the readability/maintainability tradeoff for implementing asynchronous code, which is great.

I've never seen, or more importantly experienced, an over-threaded or over-asynchronous application, ever. The problem is always the other way around, be it a 3rd party app, an in-house app, or indeed even a Microsoft app. Period. Also check out an application like iTunes. It's an under-asynchronous, under-concurrent UX nightmare. Something like async would be golden for an app like that. Or WMP for that matter.

Just to clerify, I post this has nothing to do with "Async". I am actually just watching the video for the first time right now. I see the interview, which if I imagine correctly. It is gonna be sooooo easy compare to before. I am complaining because our company is using (crap typo, I ment multi-threading) and there are so many issues. The biggest problem I have with multi-threading/ network callback is, all the code will be splited up for each handler, which become really unmanagable. Looks like I can have a much much streamlined "Async" code now. Definitly going to try it out. I actually want to use that in my school project, perfect timing if I can manage the workload.

Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.

So are you really asking when we will get "threaded coroutines"? Well when one merges the task parallel library with the Async framework, you will never need to worry about over use again; just mutable data types.. but that's been solved as well in F#!?!