Asynchronous Programming in C#

> 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

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

Only if the return types are identical.

Here’s the rub: that time will have to be spent no matter what. Async just “frees up the thread”, but the system as a whole will still have to do the same processing. Async doesn’t make a gigabyte sized I/O take less time or somehow “go away”.

In fairly extensive tests I found that it is actually pretty rare for threads to be the limiting resource, so async provided no benefit at all.

You pretty much need this specific scenario:

- A large auto-scale pool

- Tuned well to keep load at 80-90%.

- High concurrent connections per instance.

- Slow dependencies that return small volumes of data.

- A much larger back end than the front end. Think 100 VMs at the front and 10K at the back.

Violate any of the above and the benefits seem to evaporate. I’m sure that this scenario is common at FAANG sized orgs, but is extremely rare elsewhere.

This to me is the biggest drawback.

The language is truly lovely to work in, moreso than I think it gets credit for unless you've a lot of experience with it. It's just very thoughtfully designed, and MS support their own components really well and for a very long time.

The problem is that NuGet never became npm, gem or pip. The open-source community never really embraced C# (for understandable reasons) and it meant that the void there was filled largely by projects that couldn't get much traction and enterprise component vendors like Telerik.

I'm not in any way knocking companies that make their money selling these components by the way, I just think the message that people looking from the outside are seeing (rightly or wrongly) is that there's a tax payable to third parties on absolutely every level of this stack so why build with it? What's my incentive to start learning it when I can pick up node / React / Next / Python / etc. for free and start working right away with free tools? And that all shows in the ecosystem.

> all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service

Here’s 8 third-party libraries I have published on nuget in the last ~7 years: https://www.nuget.org/profiles/ConstMe

Only one of them is an SDK for a cloud service, but it’s unofficial SDK. I have no affiliation to pcloud, I only use the free version, I just carefully implemented the documented TLS/TCP binary protocol to access their cloud.

>MS libraries are great but all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service.

The biggest example are PDF producing/converting libraries, which I have no doubt make millions in licensing.

I think that might have been the case a while ago but they have even dropped .net-core and it's now just .net and cross platform.

It appears to have been the case since .net 5 (2020) (I've also stopped paying attention to MS a bit before then).

"Yes, .NET 5 is cross-platform and can be installed on Linux, Mac, and Windows. It aims to provide a consistent development experience across platforms by unifying different .NET flavors, including .NET Core, .NET Framework, .NET Standard, and Mono. .NET 5 also aligns all frameworks to support a common set of APIs, making it easier to build cross-platform libraries."

And C# is the nicest of them (because other options are worse in one aspect or another, especially performance).

What dependencies/limitations are that?

> the Java ecosystem is superior to .net, and this might be more important.

This depends a lot on what you want to do in your program. Of course, for example, for interacting with other Microsoft technologies, .net has a better ecosystem.

what about kotlin?

> How people could write "public virtual bool Equals(object other)"

Well it was created before generics in .NET one and can't be removed, that's the simple answer. But yeah, making object equality customizable virtually was probably the worst design mistake in C# and .NET. Having to specify the comparer explicitly when creating e.g. a Set collection would have been so much better for quality.

The second worst mistake was defaulting CultureInfo to the system culture (i.e. making methods like float.Parse()/ToString() take the system culture into consideration instead of requiring everyone to pass in the required behavior)

Thanks, that explains my mixed feelings. C# is very good to me, I feel very productive, but it also feels like "stricter Python" or something, which is not exactly what I expected, after being exposed to C++ for a great while. C++ occupies such a weird mix of formalism and "here's a knife, do something with the knife", but I've found that since a few years back I almost never have a program crash on me in C++. Just logic bugs. I must have found treaded garden paths.

As a C++ programmer, the first time I had to write some complex generic code in C# I was annoyed that a common C++ pattern of macros+templates for registration of factory functions wasn't directly expressible in C#. My recollection is fuzzy, but I hit exactly the inability to constraint new that you mention.

Then I found out about the ability to introspect and modify lambda expressions and generate code at startup time, which obviated the need for a template with constrained new, and I was blown away by that power.

I was also very pleasantly surprised that C# had very easy to use multiple dispatch.

So, C# is an extremely powerful, but you can't always port C++ idioms 1:1.

edit: and before you ask, yes, I'm a recovering complexity addict.

> public virtual bool Equals(object other)

.NET 1.0 was a direct copy of Java, so these Object methods are inherited from there.

It's compatible enough that it's possible to transpile Java Bytecode to run on the .NET runtime and vice-versa.

VSCode with C# Dev Kit is way to go.

I didn't down-vote.

> There are very few ways to use Task.Result and Task.Wait correctly

I don't even speak C# and I can read between the lines enough to see that they're saying 'waiting for a non-blocking method turns it into a blocking method, undoing the work of the library implementers who worked hard to provide you with non-blocking code'.

Looking at the article, I think the solution was covered in the first sentence of the first list item:

> Asynchrony is viral

> Once you go async, all of your callers SHOULD be async,

The article continues with all of the different ways you could do sync-over-async and all of them have downsides. There's no "good" solution that could be recommended.

The community consensus is to do `GetAwaiter().GetResult()` and simply accept it's not an ideal usage.

You are ignoring the problem, like the article does. await implies an asynchronous function, but impedance mismatch between two different domains may need that you execute an async-something within a sync-something-else.

Not sure why the downvotes, .Result is avoided because it causes deadlocks, so you have to only use it when you are certain it won't create a deadlock condition. The most common way is to ensure it is already awaited (which defeats the point), however you can also use "var result = Task.Run(() => myTask).Result which will work without deadlocks since you're putting it on the threadpool but you lose the thread context so it won't work for UI tasks. It's not about trying to "undo" what the language developers created, but rather about you need to already be an expert if you want to avoid using await on async methods, which means you wouldn't need to be reading these guidelines in the first place.

IIRC he worked in nuget. Not sure if he created it.

Is "creator of nuget" in his twitter bio just an inside joke?

https://github.com/NuGet/NuGet.Client/graphs/contributors lists his profile but not as a huge contributor. His LinkedIn page suggests he moved to another project after a year:

> SDE II 2010 - 2011 1 yr Co-creator and founding developer for NuGet package manager. Designed and implemented the dependency management engine for the core NuGet as well as several other features such as the initial NuGet server implementation.

As the original PM for NuGet, I can confirm that David Fowler was one of the original developers on the team that created and worked on NuGet.

He’s one of the reasons I’m still a .NET developer. Super nice guy in person.

You are clearly thinking about smaller projects. Larger projects can't survive a "stop the world" / "go async" migration. So, what do people do, they use GetAwaiter().GetResult knowing it is bad.

I was responsible for one of the largest .NET to .NET core migrations in history (3M LOC). Not a good time to also make everything async "while you are at it".

> If a company is not putting a .NET Framework -> .NET upgrade in their near future (which is a great time to go full async)

For most cases, upgrading to Core is long overdue, but also that's a very good time to change as little as possible to get it to compile and work. Only then can you think about the massive refactoring of async.

Yes.

The correct approach to this is await return has to be justified. Doing more work has to justify why this work is being done - because return await produces a whole another state machine box and async call overhead. Something that future async2 project will solve without any code changes, but hasn't become the reality just yet. The exact example in the advice is an anti-pattern (single-statement method call) that some analyzers will luckily complain about.

In order for the advice to be correct the method body should actually have either AsyncLocal declaration (exceedingly rare), or care about exact stack trace (also rare, do not rely on this as it's not guaranteed either way). If the code has a disposable, there will be a warning that returning a task of out using may be undesirable (it is common knowledge at this point).

Hence the example is as much of a mistake as doing `return await Task.FromResult(value)` over just `return value`.

> not about making every function async regardless of whether it needs it.

That's what you and I wrote. That's not what the article wrote.

"efforts to be async amount to nothing unless the entire call stack is async"

The entire call stack?

"it is best to go all in, and make everything async at once."

Go all in?

This beyond 'a little bit unclear' into 'incorrect' territory, especially since the preceding paragraph said "there's been lots of confusion on the best practices for async and how to use it properly."

Is there a single NB or asterisk-like comment on the whole page that walks back the "all in" comment to something like "calling sync from async is fine." ?

So does C# not have map yet?

(I figured `ContinueWith` was just dumb naming to avoid 'map' at all costs, just like how Java went with `thenApply`.)

AsynLocal is an advanced API you rarely deal with.

CancellationToken is a relatively idiomatic way to propagate the cancellation of operation (there are better ways! other popular languages do it even worse however).

Implicit async void delegates is also an exotic thing, you deal with it even on a more rare occasion than asynclocal (you can certainly introduce such a gotcha, but I've never seen that in practice).

Flushing the the stream or a writer is common (does not relate to async per se) because whatever you are flushing might be otherwise buffered and may not issue writes on IO otherwise when you are done with it (well-behaved implementations might safeguard you with a double-check in .Dispose(), not-so-well-behaved ones might not).

Deadlocks are specific to GUI applications which have special synchronization context, it is also only relevant when you do so from a render thread. It's something all GUI applications have to contend with in one way or another, even if the abstraction and language are different.

This article just lists known quirks that exist which always accompany the inherent complexity of writing applications that do multi-threading, possibly GUI and that may want to do "ambient state". It exists for you to simply note "aha, asynclocal, check docs when working with it" and move on. Certain points there are certainly up to debate. Which is why I noted in another comment to just not worry about it and try to write simplest and most straightforward code first and then try to fix it if you have to (which is unlikely). As long as you don't fight the language and don't ignore the compiler warnings, it'll be alright.

p.s.: if you prefer Haskell, then F# is likely to be more up your alley