Asynchronous Programming in C# • Hacker News Board

Re: Asynchronous Programming in C#

#11

Post by nobodyandproud » Fri, Sep 24, 2021, 1:28 PM UTC

only_as_i_fall wrote: post #7

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

Strong agree. I've seen devs with 20 years of experience on me write silly inefficient code because they're lulled into a false sense of security by the marketing of async/await. Multithreading is one of the hardest problems in software, and Microsoft decided that the best way to solve it is to get smart and experienced people to stop forget everything they know and instead learn a bunch of opaque apis that interact…

async/await has its place, but your application needs to be designed for it.

The most illuminating moment for me was when I realized that there is no multi-threading involved with pure async/await.

Re: Asynchronous Programming in C#

#12

Post by shikharraje » Fri, Sep 24, 2021, 1:29 PM UTC

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

Ex-.NET guy here, can confirm. Coming from JVM-land I was constantly told that async await is something that makes C#/.NET much better than Java. I personally could not understand why. Async await is not as easy as it looks, and most .NET programmers who I knew, would just hammer at things to make it work.

"Hey, this is an HTTPClient call? Put an await in front of it?" "Oh, is the IDE showing an error? Try .ConfigureAwait(false)?" "Oh, still some issue? Try putting async in the method declaration?" "Still showing an error? Remove the .ConfigureAwait() and just try async?"

At some point, Visual Studio would stop showing warnings and errors, and then the code would pass review.

Go is better in the sense that, at least people understand what a goroutine is and how/when to use it correctly.

Re: Asynchronous Programming in C#

#13

Post by mmarq » Fri, Sep 24, 2021, 1:30 PM UTC

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

Depending on the task, I find C# async/await more intuitive and complete than Go.

I haven’t used Go for a while, but you can’t await a goroutine, you have to use a channel, which is more complicated than just using ‘await’. C# has channels, so you can replicate Go’s model.

Re: Asynchronous Programming in C#

#14

Post by maxpert » Fri, Sep 24, 2021, 1:32 PM UTC

C# was my first exposure to async/await back in 2015 and I initially had trouble wrapping my head around various details (i.e. ConfigureAwait etc.). I think the languages that have done best job in removing all that detail are Go and Elixir (Beam based languages). Which if you pay attention removed the overhead of rewiring your brain to do async/await all the way down. I repeated async/await systems recently with Kotlin coroutines in JVM world and again same problem, this time due to my prior knowledge I did hit the ground running but avg Joe had to relearn.

Re: Asynchronous Programming in C#

#15

Post by bobcostas55 » Fri, Sep 24, 2021, 1:34 PM UTC

only_as_i_fall wrote: post #7

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

Strong agree. I've seen devs with 20 years of experience on me write silly inefficient code because they're lulled into a false sense of security by the marketing of async/await. Multithreading is one of the hardest problems in software, and Microsoft decided that the best way to solve it is to get smart and experienced people to stop forget everything they know and instead learn a bunch of opaque apis that interact…

async/await is not about multithreading at all though...

Re: Asynchronous Programming in C#

#16

Post by sparsely » Fri, Sep 24, 2021, 1:37 PM UTC

bob1029 wrote: post #6

We use async/await pretty much universally throughout our codebase today. One thing to keep in mind is that this mode of programming is actually not the most performant way to handle many problems. It is simply the most expedient way to manage I/O and spread trivial things across many cores in large, complex codebases. You can typically retrofit an existing code pile to be async-capable without a whole lot of sufferi…

Sometimes parallel, rather than async, processing will help there, and it's pretty easy in dotnet with .AsParallel()

Re: Asynchronous Programming in C#

#17

Post by geewee » Fri, Sep 24, 2021, 1:37 PM UTC

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

Agree as well. Not necessarily on the pros/cons list, but there's definitely a few gotchas here I didn't know about.

Re: Asynchronous Programming in C#

#18

Post by horsawlarway » Fri, Sep 24, 2021, 1:40 PM UTC

dustinmoris wrote: post #2

I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…

Strongly agree.

Honestly, just the first point "Asynchrony is viral" is a huge fucking flag that this implementation sucks.

It doesn't need to be viral, they just needed to make passing a continuation easy, and they failed miserably.

Overall - I really like most of C#, but that async/await implementation is poor at best.

Re: Asynchronous Programming in C#

#19

Post by SigmundA » Fri, Sep 24, 2021, 1:52 PM UTC

The sync over async issue is a real common problem for me when trying to get a large older codebase converted to async and you can't just do it all at once.

You still need support non async callers and you want to share code between the new async version and the old sync versions it makes it really difficult to do so.

Say you have a db layer you want to move to async but you still have to support a sync api over that, no great way to do it without hitting the potential issues, instead you have to have two versions in the db layer with no great way to share code.

What worse is when you don't even have the option to go async for instance if your not on .Net core but Framework 4.8 with the latest version of ASP MVC there is no ExecuteResultAsync on a action result so you really can't call any async code there safely, they added it to MVC core later.

Bottom line sometimes you're at the mercy of your callers and not being able to easily expose a sync version of your api when needed without a bunch of code duplication is a real problem that I have hit. I really think they should have spent more time in the beginning to allow that scenario without pitfalls and the transition would have been much smoother.

Re: Asynchronous Programming in C#

#20

Post by Amin699 » Fri, Sep 24, 2021, 1:56 PM UTC

Using Task.Result or Task.Wait to block wait on an asynchronous operation to complete is MUCH worse than calling a truly synchronous API to block. This phenomenon is dubbed "Sync over async". Here is what happens at a very high level:

An asynchronous operation is kicked off. The calling thread is blocked waiting for that operation to complete. When the asynchronous operation completes, it unblocks the code waiting on that operation. This takes place on another thread. The result is that we need to use 2 threads instead of 1 to complete synchronous operations. This usually leads to thread-pool starvation and results in service outages.