4 ms·
> 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 tr
by bouke 2y 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 2y agoI'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 2y agoThat’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.