Await Async Might Change Completely in .NET 9

Hello, everybody, I'm Nick, and in this video, I will introduce you to some plans that the .NET team has for .NET 9 that might completely change how await async works in .NET

Links:

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[jantajov]

Actially it intregues me. Perhaps you could bring us more of thees possible upcoming features.
Video idea: "5 thing I would love to have in C#" 🙂

[billybob]

That seems cool. I just hope they don't need to introduce any new keywords though.
Would be cool if older .NET projects, once rebuilt for .NET 9, transparently get the new async model.
And also deal with issues, like calling .Result from sync code causing deadlocks, so .NET 9 projects don't need copy pasted Sync and Async variants of all methods.

[DarthHwarrior]

The green thread model is a nice thing to explore and hope they do look into it again in future, but the technical document also explains problems found including some security issue found. (And that is even without Linux checked). The async2 is a beautiful example of how they want to evolve, like as you explained, instead of introducing another approach.

Though, the whole issue and most complaints surrounding Async/Await from people is also a bit annoying. It already exists for 10 years, meaning 10 years time to adopt and understand what it tried to solve back then and how to learn and live with it and accept that asynchronous models evolution take them. But still a lot of people keep resisting to try an understand the basics or willing to work with it. Especially those that are still working with .NET Framework, which in itself is still mind blowing. Companies and the teams refuse to change and adopt the mindset that it is better to first go with async due to I/O, and if you want max performance then make it better with a synchronous version if you can without all the old issue's.
Think of roads designs, in the past you had a intersection with stopping lights but async represents a roundabout, and if need to squeeze out performance you see if you can get it done synchronous but without any stopping lights. And yes sometimes the async can take a bit longer than the sync version, but you only know that after having statistics, seen enough where someone forced the sync version with I/O into it only to find out later that the system I/O got throttled and that throttled the whole application.
Most times new people seem to be more accepting of async/await and wait for it to evolve more.

Imho I think the only ones who have a right to complain regarding async/await are library API developers to a degree, as they get hit the most as they might have to provide a sync and async version, get impacted with new feature support like IAsyncEnumerable and spam everything with ConfigureAwait(false). But in the end they have to provide the optimal options as well.

It will be interesting when async2 comes around and if it will, I can expect a lot of old questions re-raised and new ones.

[Jopie]

Green threads (or fibers called in Windows) is how I used to implement async programming in c++! When I saw async/await in c# for the first time, I thought they have to be implemented using fibers. Not knowing that the c# compiler turns the method into a state machine 😮

[ronosmo]

Nick, i like railway oriented programming model (fsharpforfunandprofit). But implementing it in c# seems cumbersome right now. Async2 seems the way to go a 5X improvement is pretty stunning! If this async2 model is incorporated into the bcl we can interop with f# too. I think ms is on the right track - coloured threads are silly solution while async2 is way more sensible. Over the last 50 years of my career ive seen many pluses and minuses that have come out of microsoft. I like this considered scientific approach. It bodes well for the future. Just mc 2c.

[rotgertesla]

It might be time to have a new dotnet language very similar to c# that only keeps the new features and drop any legacy ones.

[peep]

My boss, who is staggeringly intelligent, took forever to acclimate to async/await because he came at it orthogonally and never had the time to build something from the ground up with it. That's the only way you can tame that beast. I had a similar problem, although one day the light bulb over my head turned on and I was good. No matter how many times I tried to explain it to him, it wouldn't sync in. (I mean sink)

[RioMcBoo]

Please raise a topic in support of implementing the IBinaryInteger interface for Enum structures. Constantly problems when working with elementary bitwise operations and anytime, almost also in generics.

It would also be nice to implement the ICanBeArrayIndex interface for all basic integer structures and Enums that are equal in size or smaller than Int, so that they can also be used in generics without unnecessary conversions and boxings.

Officially Enum allows only integer types, it makes sense.

[antonyba]

Just noticed, your head bubble should be in the right bottom side. It is blocking content very much. Thanks for the good content

[matthewsheeran]

I have avoided and never use async/await since it appears to be turtles all the way down (and up!) once you start to do so!

[robl]

Just make everything a readonly ref struct value task AOT and things will be perfect

[synthaistudio]

Thread was locked. Awaited for this for so long.

[LCTesla]

I've always liked the idea of _communicating_ that an operation is I/O bound with the async keyword, but a lot of people (guilty as charged myself) forewent doing that in lieu of making everything async. Hopefully we can go back to using async where it is actually communicatively meaningful and use green threads in the default case scenario, and have major performance reasons to maintain that kind of discipline. Unfortunately, if async2 is really so incredibly performant, laziness in communication might still prevail.

[ambafatalbatymalion]

Another great video! I have one suggestion. It'd be good to move your camera to the right when you are on the GH issue page. So you don't cover the description when you are going through it ;)

[protox]

Interesting... I'm curious how the performance compares to my async library that's already faster than tasks. I'll have to check it out.

[EdKolis]

I remember thinking earlier that maybe in a future version of C#, we'd not need to say async for asynchronous methods, but instead everything would be async by default and you'd have to manually specify that you want the method to block. Maybe this is a step in that direction?

Or what if someday we can alias keywords and give them new names or alternate behaviors? 😛

[yufgyug]

so what exactly does 'runtime handled tasks' mean? instead of state machine code being generated on csharp level, its gonna be generated with cpp on runtime level or something?

[MykytaNikitenko-wc]

"Write a synchronous code which will work behindly asynchronous" Microsoft will invent Go! :)

[bonkers_dave]

just wondering whether this work on lower C# and aot ends up with a new embedded model for rom-ability.

[julianjupiter]

Is it more or less the same as Virtual Threads in Java?