Asynchronous Programming in C#
github.com
Asynchronous Programming in C#
1–10 of 186 posts
Re: Asynchronous Programming in C#
#2I 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 all that it's actually not that easy after all. When I compare this with goroutines I do sometimes wish .NET would have a Go like model instead.
Re: Asynchronous Programming in C#
#3I 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…
You can get closer to the Go experience if you just ignore all the tuning knobs and not try to optimize performance. .NET 6 is reducing the penalty of some of the gotchas too, so things are getting better.
Re: Asynchronous Programming in C#
#4Is there a particular reason this has been posted today?
The last commit to it was in April.
It's a good list for sure, just wondering why it's popped up on HN
Re: Asynchronous Programming in C#
#5I 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…
I don't think there are really ways to do async programming that don't have gotchas. It's just inherently complicated.
And of course C#/.NET is a bit older and also very large, it has more surface area for weird behaviour that might not be easily fixable due to backwards compatibility.
Things like using void as a return type for an async function can be a nasty surprise if you're new, but this is not an issue at all once you know this (or if you simply used the right examples and used Task from the start). It's not a subtle gotcha.
Sync over async is much sneakier and can be very nasty. But I'm not sure you can avoid this when interacting with a language/environment that used to be mostly sync and switched to async. If everything is async you don't have this issue, so this is better for newer codebases.
Re: Asynchronous Programming in C#
#6We 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 suffering.
If you are trying to go as fast as possible, then async is not what you want at all. Consider that the minimum grain of a Task.Delay is 1 millisecond. A millisecond is quite a brutish unit when working with a CPU that understands nanoseconds. This isn't even a reliable 1 millisecond delay either... There is a shitload of context switching and other barbarism that occurs when you employ async/await.
If you are seeking millions of serialized items per second, you usually just want 1 core to do that for you. Any degree of context switching (which is what async/await does for a living) is going to chop your serialized throughput numbers substantially. You want to batch things up and process them in chunks on a single thread that never gets a chance to yield to the OS. Only problem with this optimization is that it usually means you rewrite from zero, unless you planned for this kind of thing in advance.
Re: Asynchronous Programming in C#
#7I 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 with an incredibly complex internal state machine.
It hardly seems worthwhile to me.
Re: Asynchronous Programming in C#
#8Is there a particular reason this has been posted today? The last commit to it was in April. It's a good list for sure, just wondering why it's popped up on HN
Would it be different somehow if the last commit was, oh, yesterday?
Re: Asynchronous Programming in C#
#9I 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…
I don't think there are really ways to do async programming that don't have gotchas. It's just inherently complicated. And of course C#/.NET is a bit older and also very large, it has more surface area for weird behaviour that might not be easily fixable due to backwards compatibility. Things like using void as a return type for an async function can be a nasty surprise if you're new, but this is not an issue at all…
Sure, but I'd argue that the best way to handle this is to just stick to the already existing paradigms that developers have experience with. It's not like there are any problems which can't be solved without async or tpl, and it's not like Microsoft wants to introduce a similar paradigm outside of the .net ecosystem, so it's just creating an artificial barrier and making the code harder to understand so that they can post clean looking examples on their doc pages.
Re: Asynchronous Programming in C#
#10Is there a particular reason this has been posted today? The last commit to it was in April. It's a good list for sure, just wondering why it's popped up on HN
Would it be different somehow if the last commit was, oh, yesterday?
just wondered if it was relevant to some other discussion I'd missed. that's all