All in all, extremely appalling sentiment and consensus in the comment section.
All good and informative responses that provide actionable feedback to raised concerns are downvoted, and simply incorrect or outdated statements are upvoted.
Please try the language and the features it offers with modern templates first before leaving feedback that is based on assumptions and impressions about things completely unrelated to C#.
People are requesting that the author write 'the right way' to synchronously return from an async method, since he recommended against blocking... am I having a stroke?
That said,
> Please try the language and the features it offers
I did walk away with a much worse impression of C# after reading this article. I knew not to wait on async (because then it's sync) before this (By definition! in all languages!) But now I know that it might also deadlock.
The other thing I got from the article (not the comments) is just how much machinery and wiring is left lying there for the app developer:
AsyncLocals?
CancellationTokens?
Implicit async void delegates?
FlushAsync on StreamWriters before Dispose?
AsynLocal is an advanced API you rarely deal with.
CancellationToken is a relatively idiomatic way to propagate the cancellation of operation (there are better ways! other popular languages do it even worse however).
Implicit async void delegates is also an exotic thing, you deal with it even on a more rare occasion than asynclocal (you can certainly introduce such a gotcha, but I've never seen that in practice).
Flushing the the stream or a writer is common (does not relate to async per se) because whatever you are flushing might be otherwise buffered and may not issue writes on IO otherwise when you are done with it (well-behaved implementations might safeguard you with a double-check in .Dispose(), not-so-well-behaved ones might not).
Deadlocks are specific to GUI applications which have special synchronization context, it is also only relevant when you do so from a render thread. It's something all GUI applications have to contend with in one way or another, even if the abstraction and language are different.
This article just lists known quirks that exist which always accompany the inherent complexity of writing applications that do multi-threading, possibly GUI and that may want to do "ambient state". It exists for you to simply note "aha, asynclocal, check docs when working with it" and move on. Certain points there are certainly up to debate. Which is why I noted in another comment to just not worry about it and try to write simplest and most straightforward code first and then try to fix it if you have to (which is unlikely). As long as you don't fight the language and don't ignore the compiler warnings, it'll be alright.
p.s.: if you prefer Haskell, then F# is likely to be more up your alley
All good and informative responses that provide actionable feedback to raised concerns are downvoted, and simply incorrect or outdated statements are upvoted.
Please try the language and the features it offers with modern templates first before leaving feedback that is based on assumptions and impressions about things completely unrelated to C#.