There are a ton of rules to memorize, compared with using a language such as Go that hides the complexity of async. Linters can help check and correct code, but they can be cumbersome to setup.
I wonder if there will eventually be a new mode for C# or even a new language for the CLR that does away with sync I/O completely, and makes async easy to do correctly.
Not an argument for one or the other. Go's restrictiveness can be seen as a benefit, C#'s flexibility can be seen as a time waster.
> ...or even a new language for the CLR that does away with sync I/O completely, and makes async easy to do correctly.
Well, your caveat "for the CLR" means I have nothing to suggest. If it weren't for that, there are tons of languages (new and old) that approach concurrency differently.
For that I find the explicit async/await quite valuable. Could non textual code highlighting in modern editors do that as well: Sure, but that is not the tech of 10 years ago when C# team came up with that.
I don't thing async helps with this. People will always write code like everything is in memory. My feeling is the best antidote is to artificially introduce worst case latencies even when developing locally so the pain will be felt during development instead of production. Perhaps static analysis could help as well.
async/await in C# is easy. Trying to be clever and reinventing the wheel, arguing with a compiler or not going for the simplest and most straightforward option even when you are presented with one makes it not so.
Have a "main thread"-style flow of execution that doesn't want to be async nor is a UI thread (which has special handling)? Just .GetAwaiter().GetResult() it. Or vice versa - block the worker thread if you really want to.
The reason the advice exists like the one being linked is developers abusing certain areas has historically been leading to proliferation of very sloppy code. Threadpool is perfectly happy if you have a particular heavy blocking syscall, like DNS used to be. It will work just fine, auto-scale worker threads to reduce work item pressure in queues and otherwise proactively mitigate this.
You don't have to worry, even if people ask you to, often out of puritanical considerations (like not mixing async and sync, even when it's the easiest and not an issue).
That won’t work with various synchronization contexts, where doing this would cause a deadlock. There’s not much fun in trying to debug such issues.
And now that various libraries only provide async api, or worse an non-async version wrapping the async one with . GetAwaiter().GetResult(), you’ll be in for a treat updating your dependencies.
Async all the way is the answer, although various frameworks still don’t offer async hooks. Recently I ran into this for example trying to write an async validator in blazor, but that’s not possible and you have to work around it [1].
C# 5 introduced async/await almost 12 years ago. And we’re still not “async all the way”.
Or developers that used to work with something long time ago and never revisited their knowledge.
Or participants in the conversation which have strange, inappropriate and unrealistic expectations pitted against .NET but not any other technology, which would go out of their way to post something that is factually incorrect, simply out of desire to be controversial (I can shit on Go all day, but I'm not going to lie about its pros and cons).
In my 10 years of experience writing in a language that I like and I think I know rather well, I cannot share your view that “async/await is easy”. The happy path is easy, but you’ll hit show-stopping issues when you’re building big complex systems.
This is not complex at all once you grasp the basics. It all trickles down from there.
> the complexity of getting async “right”
Promise (JS) = Task (C#)
Promise<T> (TS) = Task<T> (C#)
Promise.all() = Task.WhenAll()
C# has to be one of the more approachable languages for most teams that are already versed in JS/TS because of the similarity[0] and influence of C# on JS and TS (JS async/await came after C#; same for JS lambdas)