The article would have been interesting if it had proposed a solution to this problem, but instead they just brushed it away as if it was pointless.
A solution is obvious – use await instead. Modern versions of the language even support async main function.
Modern asp.net is designed in async-only way, no impedance mismatch there.
async void functions are compatible with non-async delegates. This solves impedance mismatch for GUI frameworks or other event-driven apps. Just don’t forget to catch and handle exceptions from the async code inside, also for GUI apps show users that background operation is ongoing.
The standard library exposes both flavours of APIs for files, sockets and many other built-in classes. You don’t have to use async APIs unless you want to.
The community consensus is to do `GetAwaiter().GetResult()` and simply accept it's not an ideal usage.
The ideal solution is to split the code and continue the execution through an event/continuation/queue, etc...
I'm sorry, it looks like you did not get the problem: you receive a Task, and you are in a sync environment, and you don't have control over these two constraints. How do you safely wait for the Task to complete?
So basically: you have to call async from a synchronous context. But I think perhaps the article correctly avoids the topic, because in 99% of cases when you think you need to do this, you don't. And having an easy googleable page with an easily copied recipe for doing so could do more harm than good.
In the end it's going to be extremely rare that you can't bend over backwards to refactor your callsite to be async. E.g. you are in a constructor (which is sync) and want to call an async method. The solution isn't to wait on a result, the solution is obviously to not call it from the constructor. And that's the solution even if you have to refactor for a week instead of a blocking wait.
But yeah I agree he could have included the answer, surrounded by big red warning sigs that you probably don't need to, or want to copy it.
Perhaps the key clue is to give the good pointers to solving it properly. Just saying "you have to be async all the way" isn't really helpful. One key insight I got from somewhere was that identifying the async starting points was the key. E.g. for a desktop app, the realization that in 90% of cases your async "root" will be a GUI event, and that these event handlers in the GUI frameworks like WinForms or WPF can be async whenever you want. As a last resort, your main() method can be async.
> There are very few ways to use Task.Result and Task.Wait correctly
I don't even speak C# and I can read between the lines enough to see that they're saying 'waiting for a non-blocking method turns it into a blocking method, undoing the work of the library implementers who worked hard to provide you with non-blocking code'.
Looking at the article, I think the solution was covered in the first sentence of the first list item:
> Asynchrony is viral
> Once you go async, all of your callers SHOULD be async,
If you can't fathom that calling code could be written before, or independently from, or in a different domain than. called code, than you've never developed complex code.