29 ms·

Go simply cannot easily solve certain problems that async/await can. It is a weaker language in this regard that has to resort to channels and wait groups even

Go simply cannot easily solve certain problems that async/await can. It is a weaker language in this regard that has to resort to channels and wait groups even if those are undesirable and unidiomatic. And when it faces a problem that requires async/await, the solutions are not pretty. 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).

bouke 3y ago
> Just .GetAwaiter().GetResult() it. 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”. [1]: https://github.com/dotnet/aspnetcore/issues/40244 https://github.com/dotnet/aspnetcore/issues/40244
- neonsunset 3y ago
  I'm so tired of developers that don't bother to read the text they are responding to and immediately assume that the other party in the conversation does not know what they are talking about. 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).
  - bouke 3y ago
    That’s fine by me. 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.

bouke 3y ago

> Just .GetAwaiter().GetResult() it. 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”. [1]: https://github.com/dotnet/aspnetcore/issues/40244 https://github.com/dotnet/aspnetcore/issues/40244

neonsunset 3y ago
I'm so tired of developers that don't bother to read the text they are responding to and immediately assume that the other party in the conversation does not know what they are talking about. 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).
- bouke 3y ago
  That’s fine by me. 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.