4 ms·
It is quite annoying for older codebases in C# that have a lot of existing sync code, but for new code it doesn't matter all that much. You use async methods fo
by fabian2k 2y ago
It is quite annoying for older codebases in C# that have a lot of existing sync code, but for new code it doesn't matter all that much. You use async methods for IO and DB access and in many applications this means that most of the methods will be async.
I only played around with it a bit a long time ago, but I didn't find Go concurrency as simple and easy as it is often sold. It felt very low level, which is fine for the design goals of Go, but also meant that I was still left with doing some harder parts myself.
Concurrency in C# with async/await is pretty easy for the straightfoward cases that make up most of a typical application. You do have to keep to a few rules and it certainly has very dangerous footguns, but those are minimized if you use consistently use async methods instead of sync.
- achr2 2y agoThe only real landmine for c# is the default thread synchronization. If it was inverted, the language would be much better off. I think they also made a mistake in removing the OOTB method for throwing away the sync context, but I guess there are many third party libs that provide it.
- fabian2k 2y ago.NET Core web apps have no synchronization context anymore, which is exactly what you're asking for if I understand you correctly. There is no need to call ConfigureAwait there. I think this is different for GUI apps, but I have no experience with that.