9 ms·

I like C# a lot, but the complexity of getting async “right” is a turn-off to new developers learning the language. There are a ton of rules to memorize, compa

I like C# a lot, but the complexity of getting async “right” is a turn-off to new developers learning the language. 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.

HumblyTossed 2y ago
It’s even a “turn off” for some of us more experienced devs. It’s annoying that it has to be “async all the way down”. It’s annoying that they make libraries that are async instead of leaving that decision to the developer, etc. Go’s concurrency solution is more enjoyable.
uticus 2y ago
C# is definitely more flexible than Go, which is by design on both sides. 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.
neonsunset 2y ago
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 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 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 2y 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.
oaiey 2y ago
While I agree for the early learning, it is also very valuable for the later learning ... since it puts focus on where you write crapy code. When you loop around a resource access code 10.000.000 times, then you go in/out of your process for that often. 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.
- osigurdson 2y ago
  > When you loop around a resource access code 10.000.000 times 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.
CharlieDigital 2y ago
> the complexity of getting async “right” For most single-context use cases, it's no harder or difficult than async/await in JavaScript and hardly anyone would call JavaScript "complex". Promise (JS) = Task (C#) Promise<T> (TS) = Task<T> (C#) Promise.all() = Task.WhenAll() For multi-context use cases, there's just a bit of awareness required to understand that you may need continuation on the original thread and awareness of context-sensitive resources. But if you're building web API backends, most of the time, it's not a concern and async/await works (mostly) like JS because the dependency injection container is playing a big role in handling object scopes. 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) [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
thefz 2y ago
> I like C# a lot, but the complexity of getting async “right” is a turn-off to new developers learning the language. This is not complex at all once you grasp the basics. It all trickles down from there.

HumblyTossed 2y ago

It’s even a “turn off” for some of us more experienced devs. It’s annoying that it has to be “async all the way down”. It’s annoying that they make libraries that are async instead of leaving that decision to the developer, etc. Go’s concurrency solution is more enjoyable.

uticus 2y ago

C# is definitely more flexible than Go, which is by design on both sides. 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.

neonsunset 2y ago

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 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 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 2y 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.

oaiey 2y ago

While I agree for the early learning, it is also very valuable for the later learning ... since it puts focus on where you write crapy code. When you loop around a resource access code 10.000.000 times, then you go in/out of your process for that often. 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.

osigurdson 2y ago
> When you loop around a resource access code 10.000.000 times 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.

CharlieDigital 2y ago

> the complexity of getting async “right” For most single-context use cases, it's no harder or difficult than async/await in JavaScript and hardly anyone would call JavaScript "complex". Promise (JS) = Task (C#) Promise<T> (TS) = Task<T> (C#) Promise.all() = Task.WhenAll() For multi-context use cases, there's just a bit of awareness required to understand that you may need continuation on the original thread and awareness of context-sensitive resources. But if you're building web API backends, most of the time, it's not a concern and async/await works (mostly) like JS because the dependency injection container is playing a big role in handling object scopes. 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) [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp

thefz 2y ago

> I like C# a lot, but the complexity of getting async “right” is a turn-off to new developers learning the language. This is not complex at all once you grasp the basics. It all trickles down from there.