Await Async Might Change Completely in .NET 9
Vložit
- čas přidán 7. 01. 2024
- Check out my courses on Dometrain: dometrain.com
Become a Patreon and get special perks: / nickchapsas
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:
github.com/dotnet/runtime/iss...
github.com/dotnet/runtimelab/...
github.com/dotnet/runtimelab/...
github.com/dotnet/runtimelab/...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
Let's await the results 😶🌫
heh
lol I see what you did there :)
I hope this is not a fire and forget experiment!
You never know. We might need to await2 the results.
@@NeverSinkdidn't expect to see you here 👁️
Give the dotnet team your energy! 🫠
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#" 🙂
If you guys can tell bill gates I need these two urgently:
- Discriminated Unions
- Inheritance from a generic parameter
Thanks
@@parlor3115 Bill gates has no involvement in the language or runtime.
@@protox4no way, who's adding all of these new C# features if Bill Gates is not in the picture anymore?
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.
Just calling ".Result" from synchronous will not always cause deadlocks, nor GetAwaiter().GetResult()
You have to understand where you are calling it and why it can cause it, a new model will not just solve it. The Green thread model could in a way, but even that would still have such scenario's (it is not fool proof).
If everything from top to down is sync and you call a point that is async and then one of the two solutions then there will be no deadlock, as long strange shared values are changed with locking mechanicsms or so. But if there something else is async interacting with it in the whole flow then yes.
You're always bringing the gold Nick, thanks buddy.
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 ;)
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.
As if our job wasn't complicated enough already... WOW! Well, whatever they decide to do, it better be backwards compatible! I feel that C# is already evolving way too fast for some of us to catch up as is! And TWO simultaneous await / async models doesn't sound like a good approach! A far better one, once they work out ALL the details (and the damn bugs!) would be to make this some kind of optional compiler switch, to use the new features via existing syntax, so that we can continue to work in an *explicit* way when it comes to tasks.
Async code SHOULD look different to sync code! To flag to future developers, the nature of the code bases that they have to work on. Totally abstracting away the async / sync model, just sounds like a BAD idea! Sure, it might help weaker developers get up to speed more quickly, but at the expense of code becoming more difficult to understand under the hood! We already have enough abstraction as is!
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 😮
There's a great video on the internals of async/await by the channel Raw Coding, and the state machine specifically. Really interesting stuff
As far as I know, c# thread pool is built on the fibers
@@kkk-tk6gq I strongly doubt that. With Windows fibers you have to manually switch to other fibers using a Windows API call switchToFiber. With that call the callstack and instruction pointer (and maybe even more) of the current thread is replaced with the one from the new fiber.
The C# thread pool is as far as I know using autoswitching threads which switch using the OS scheduler.
Hi Nick, I bought your rest API course.
My question is in the project that consumes the api can I use dtos that there are in movies.contracts or should I create different dtos for the consuming project?
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.
Hi Nick, given the experimental difference between the two models, would it make sense for Microsoft to implement a config setting to the appsettings.json to run one implementation vs the other on existing set of projects? Given existing projects allowing teams to easily benchmark each approach across a wildly distributed application?
Thread was locked. Awaited for this for so long.
Awaiting for await3
just wondering whether this work on lower C# and aot ends up with a new embedded model for rom-ability.
Hey Nick, @3:30 you say that async await came at a time when MS couldn't touch the CLR, but now they can. Could you elaborate or point me where I can read more about this?
.Net Framework was(and still is) built into Windows. Changing it is immensely costly.
.Net Core and onwards isn't, so the barrier to entry is way lower. It still requires (at least partial) support in all 3 major languages however, so there's still a fairly sizable barrier, but nowhere near as big
@@modernkennnern Also at that time they were trying extremely hard to provide backwards compatibility for everything (.Net 4 was released in 2010 and is still supported to this day). Now they pump out a new major version of .Net every year.
"Write a synchronous code which will work behindly asynchronous" Microsoft will invent Go! :)
Java actually went the green thread approach (Loom/Virtual Threads), and so they have Go-like behavior now, with no function coloring, I even saw some (no clue how correct are they) benchmarks that showed Java's Virtual Threads to be faster than Go's solution (which was among the best results)
It is not about inventing it. It is more like merging the best ideas into the language if it fits.
And as a note for the "if it fits" part: C# language decision board is deferring the discriminated unions (and monads at all) for years by now. Don't know the reason tho.. :/
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? 😛
Async doesn't tell the method whether to block or not. Await does that. Async keyword is used just for backward compatibility with the old code which might've used "await" as an identifier instead of a keyword. For that reason, if they make all methods async by default, it will break backward compatibility.
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.
Is it more or less the same as Virtual Threads in Java?
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.
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?
Just noticed, your head bubble should be in the right bottom side. It is blocking content very much. Thanks for the good content
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.
This to me is the biggest problem with async code. You can only await something in a method which is async. But if you make your method async, you can only await it from another async method. Meaning everything has to be async all the way to the main function. But that seems like overkill.
@@davidwilliss5555 This isn't just a c# thing as well, I've found the same issue in Rust and Python with writing async code. it just feels like your complicating the whole program when you really only want it in one or 2 lines.
@@davidwilliss5555what's the problem with that? If you don't want to make the parent method async, then don't await the child method. Use continuations or smth else instead.
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!
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)
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.
They already have - it's called F#
The recent C# versions have been a lot of taking what they can from F# and back porting it into C#
@@orterves there is a reason why F# has not caught on. Better to start from scratch, and design the language in a way that is attractive to most programmers.
@@evancombs5159 the reason F# hasn't caught on is inertia in the ecosystem and the lack of support for F# as a first-class option for business system development. Once you learn the language, it's the friction between using F# and existing .net libraries and processes that slows adoption - though for most use cases it's possible to get it working, there's little help online if you run into issues.
So, what you're proposing is to create a whole new language that doesn't have these issues? Just stick with C# as it evolves or fix the friction between F# and the ecosystem. There's no need for another language
I agree with that
I think it's not just the language, but also the framework classes. e.g. ArrayList, Random still uses the old slow/buggy prng and sampling internally when constructed with a seed, lots of methods that now take a span but they still need to maintain the original signatures using string/array or whatever. I do think eventually it would make sense to cleanup the really old stuff and just call them out as a breaking changes well ahead of time so folks have chance to migrate their code away. I guess you could also move some of the old classes/signatures to nuget packages maybe, to give people the option of keeping old code alive with minimal effort. I don't see this happening anytime soon though, if ever.
Just make everything a readonly ref struct value task AOT and things will be perfect
Interesting. I hope this enhances the async/await model of C#, nipah~☆!
Why do they use struct in release but class in debug?
@@dzllz but why not use struct for both? Is there some benefit to using class in a debug environment?
@@GBreen12 I mean that is the only logical assumption.
@@GBreen12 Hot Reload. The compiler can edit a class and add fields in there and emit new IL, but not a struct since struct sizes are supposed to be compile-time constants
@@antonzhernosek5552 nice! thanks for explanation
9:09 ConfigureAwait 😹
As if our job wasn't complicated enough already... WOW! Well, whatever they decide to do, it better be backwards compatible! I feel that C# is already evolving way too fast for some of us to catch up as is! And TWO simultaneous await / async models doesn't sound like a good approach! A far better one, once they work out ALL the details (and the damn bugs!) would be to make this some kind of optional compiler switch, to use the new features via existing syntax, so that we can continue to work in an *explicit* way when it comes to tasks.
Async code SHOULD look different to sync code! To flag to future developers, the nature of the code bases that they have to work on. Totally abstracting away the async / sync model, just sounds like a BAD idea! Sure, it might help weaker developers get up to speed more quickly, but at the expense of code becoming more difficult to understand under the hood! We already have enough abstraction as is!
I like go because unblocking IO is not colourd.
Coloured functions are a big problem because they are a leaky abstraction and sometimes a costly one, too.
ValueTasks kinda solve some perf issues, but the ergonomics are still very bad.
The point of having a future/task/promise is a Functor, the problem is that now every function need to be raised as well, making the syntax messier and forcing me to "think ahead" which is the root of all evil.
I can't describe an interface for a class i work on without needing to think about how the implementation of this interface should work, this defeat half of the reason for interfaces to begin with.
Async IO should be the default in languages like C# where the thread pool is implicit anyway.
Async IO is the preferred method of doing IO 90% of the time. Sync IO makes sense only in small amounts of cases like scripts, cli tools, or basically any software that dont need concurrency. But even on cases where sync IO is preferred, in most cases, doing it async anyway has little to no value reduction, unlike the opposite.
Just give me the F# MailboxProcessor / Erlang process / Go channel / Actor model with green threads in C# please
Many comments on here don't seem to understand the difference between greenthreads and what they're doing in .NET 9.
Anyway, I think a .csproj setting for preferred async handling, and making it mutually exclusive, would help with most concerns that I'm seeing with those in the "nay" camp.
Extending that, maybe make it like nullable so it can be set per file
@@plantyheatmat exactly what I was thinking, yep.
Why not for the first solution, but only if it is compatible with dependencies, which i doubt. Because threading is independant from files, your last proposition will not work.
Primary constructors, now this. PLEASE do not do such changes. Current async/await method is fine and much much easier/simpler than other languages. Why do you want to change this? There is no reason to change this. Please do not disappoint dotnet community. We are trying to bring new people to language, but such changes will make existing community to leave/switch language. An unpopular opinion.
I'm strruggling to comprehend the motivation behind these changes.
Is current async await model performance costs THAT big, that it's worth to introduce yet another async model in C#, potentially making a huge mess out of it?
Doing so just for sake of hiding away asynchronicity from devs seems like inherently bad idea.
It seems like a very bad idea indeed.
That's why they didn't move on with it.
The new experiment to me seems like they are abandoning new model and experimenting instead with vastly improving the current one
I think green threads are a better solution
Don’t await. Get awaiter and keep it somewhere. Do what you were doing. Call await a few months later 😀
It’s probably just me, but honestly, these frequent and rather drastic changes to language every release or two kinda put me off and make me not want to invest too much into master the language.
Luckily I have the freedom to choose the tech stack I’d be working on…
Concurrency without the 'function coloring' problem is one of the only cases where Java is actually ahead of the curve.
Who even cares about that debate when IDE support is good and unlike JavaScript, you can run async methods synchronously if you want to.
@@Alex-kb2ws We have those too.
Keep it salty.
Read java and javascript in two different comments, not quite the same thing ngl
You mean all 15 projects that use greenthreads and loom?
@@nocgod It came out 3 months ago and is also irrelevant.
If they don't stop with the rollercoaster changes in .Net and C# I'm going to drop them like a bad habit. And it'll be the best decision I've made since switching to C# in 2012.
a second async await framework makes things messy. i prefer to keep the current contact
They wanna (have to) keep the previous model for backward compatibility reasons. But if the old approach is slow by modern standards, it is understandable that they wanna move forward with a faster variant.
imo, they should focus more on enhancing the type system. 10 years ago C# was one of the best languages in regards to what and how easily you could express things but lately they are focusing more on introducing half-fetched functional programming concepts and syntactic sugaring. Now, newer languages feel much easier to work with considering how easily you can define things without having to fight with the compiler all the time or use some tricks like recursive generics. Good example is F# but also Rust, Scala (well even Go). I feel like they are still stuck in 2010 with this mindset and the vision for the language.
An example would help your comment a lot
Take DDD as an example especially domain model is always a pain to define (e.g. value objects, discriminated unions, absence of data, validation errors, etc.)
Also nullable reference types.. what the hell. After LINQ, pretty much no improvement for declerative way of writing code (maybe match expressions but honestly that is a minor one)
@@hcerim Nullable Reference Types is by far the best recent addition of the last few years to make C# safer and make NullReferenceExceptions rare instead of way too common.
@@MaximilienNoal this could've been done by introducing the actual type like Option or Maybe together with monadic behaviour and actually solving the issue by enforcing developers to handle possible absence of data and making it less possible to define and not just masking it on the surface level.
if it works better great, but if it's better or worse, implemented or not, i dont like that they are hiding away more under the hood implementation details. there's always a case where leaky abstraction causes someone to dig deep into documentation to discover an odd niche error. i want brevity, i want explicit naming conventions. but we're talking about MS here.... lol
I'm just confused you call it "await async" and not "async await" lol
Removing the await keyword from a Task returning method is bad for refactoring, and a useless micro optimization IMO.
It isn't. Your IDE and/or resharper will complain that your method is not async anymore if you refactor/add new lines to that method.
It's standard, especially for InvokeAsync middleware with many early return statements. Why pay the state machine for some awaits at the bottom when it's not executed most of the time?
That is not what this experiment is about.
It seems that they don't want to stop adding new features with every release, they make the language harder and harder to learn
It becomes harder to master, not necessarily to learn. I think it's better for a language to provide options than impose limitations.
@@bluecup25
it is not about limitations anymore, it is about adding unnecessary features, i would prefer if they can just stop adding more features and focus on what they already have and improve it. I believe that Go approach is the best, they do not add new features unless it is necessary.
Hard to understand your complaint as this doesn't even change anything in the language itself...
@@emmanueladebiyi2109
I'm not talking about this one specifically, I'm talking in general. They don't want to stop adding new features with every release, for example, C# contains the largest number of keywords compared to any other language, it is easy to write bad code in c# thanks to that, and it is hard to master it.
I would call this an optimization, not a new feature.
Kind of hard to manage the compatibility with old libraries with this.
How? If it is a new keyword there is no impact.
@@jfpinero A new keyword is always a breaking change
@@jfpinero It's going to replace the current one, as far I as I understand it. But then you should be able to use await on all the existing libraries on nuget as well. Or not, depends on what they choose to do.
@@pagorbunov no it isn't, you are not forced to use it or upgrade to it.
@@jfpinero someone might use that keyword as variable name for example. so new keyword would break that code
Before taking on a completely different model making huge changes to the complier infrastructure, how about solving the coloring problem first?
Declaring a function as Async and changing the return type colors a function.
I would guess, that keyword can be made obsolete/optional by the compiler infering from the code (ie. are async API being attached to var or a non-task-type).
var x = File.OpenAsync -> await
FileStream = File.OpenAsync -> await
Task = File.OpenAsync -> no await
Every method with an implicit await -> async
In this scenario, every method upstream will inherit its Async marker and return type rewrite from the call infrastructure, straight up to the main method. And yes, a change in layer 5 will change 4 layers above. They have to, anyway.
This would be backward-compatible, would realize the power of choice to use keywords if needed and requires no runtime changes.
Once done, they can still change the underlying await logic ie how those futures are executed by the runtime.
It would be a breaking change to all existing codes. var usually translates to Task than FileStream. People using var would break.
hi
Another way of running nonblocking asynchronous code? Like IAsyncResult, Threads, ThreadPool, Task TPL, Async/Await Tasks, Async/Await ValueTasks, NamedPipes, MailboxProcessor, etc. Why don’t they focus on improving the language and ecosystem without compromising the developer experience or setting back an entire ecosystem of libraries that were written in csharp. No wonder dotnet ecosystem is not as reach and vast as Java. Microsoft doesn’t do library and framework developers any favour with these changes.
Hard pass
bro u need to change ur company name , DUMB TRAIN makes no sens