Hacker News Reader

Because blocking on tasks is a deadlock waiting to happen [0], and creates UI hiccups when the task takes longer than 16ms to complete.

In other words, the conditions you must satisfy for using Task.Wait or Task.Result are very complicated. They depend on and create global constraints of the entire program, and so you should avoid using them whenever possible.

0: http://blog.stephencleary.com/2012/07/dont-block-on-async-co...

That deals particularly with mixing and matching awaits and Results in complex manner. I wouldn't call "don't do that" "very complicated".

My mistake and too late to edit. I don't use "await" and I misread this at first. Actually the classic tasks way would be to add these to an array of tasks, and then "WhenAll" for the continuation.

yes it's easier to fire and wait for async tasks in parallel - but I specifically mentioned processing serial async responses, i.e. sequentially like a normal for loop.

isn't this whole discussion predicated on not wanting to block? if you don't care about that there's no need to call a Task-returning method in the first place.