, vesuvius wrote

You could always use the background worker component, it is not a language level component, but has yet to be equalled when it comes to ease of use and reporting progress.

I realise that a background worker is cumbersome for something like WinRT, the reason the async and await are so useful, is that anything between 50%-90% of the time, you are making web service calls, or starting/suspending applications where progress reporting is not required. If you do have a granular procedure that requires progress reporting, then .NET already has APM and EAP, where TAP and your exposition is merely the new kid on the block.

BackgroundWorker uses a background thread. Not all asynchronous operations require a background thread, and so BackgroundWorker is a pretty heavy weight solution. Moreover, the only thing BackgroundWorker provides over IProgress<T>/CancellationToken is designer support... which honestly I question the utility of. IOW, I'll have to disagree with your assertion that it "has yet to be equalled when it comes to ease of use and reporting progress." In any event, exoteric has already dismissed this with "but at that point algorithms start to become less elegant in my oppinion." He didn't expand on that, so I'm not sure why he has this opinion, but BackgroundWorker isn't going to cut it for him.

Me, I find Rx to become horribly complicated rather quickly. It's great for small things, especially in handling UI events, but it doesn't scale well. Part of that stems just from not having a lot of solid functional experience, but unless you're developing on your own that's something to keep in mind, because I have a lot more experience here than your average .NET developer. Also, I think part of it is from design problems with Rx. Given a choice between Rx and async/await with IProgress/CancellationToken I'll take the latter 9 times out of 10. I believe the resulting code is easier to understand and maintain, especially for your average .NET developers.

I think async/await code composes fairly nicely, though there are some tricks one has to learn in order to ensure good results. Asynchronous coding is hard, plain and simple, and I don't think anyone's found a silver bullet for it yet, nor am I overly optimistic that anyone will. I like the mixture of solutions available to us in .NET, because the various solutions are each the best choice for specific scenarios. I'm also looking forward to the writeable/readable/immutable/isolated changes being researched, which is another key component in this whole discussion.