Await Async Tasks Are Getting Awesome in .NET 9!

Until the 21st of April, buy ANY Dometrain course and get the From Zero to Hero - LINQ in .NET course for free!! dometrain.com/...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I will introduce you to a brand new await async and Task feature coming in .NET 9!
Workshops: bit.ly/nickwor...
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elf...
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet

[@tehsimo]

Lovely feature BTW that zoomed middle region messes with my brain

[@DredTather]

For concurrent processing, there's also the channels library that's been available since .net core 3.1 and the excellent channels.extensions library that makes it so much easier. I'd love to see a video on this.

[@yuGesreveR]

OMG!!! I've been waiting for this feature for years!

[@sinan720]

You could've just used System.Linq.Async. This functionality has already existed for years

[@Ilix42]

Great video as always. One bit of feedback, please provide a link to referenced blog posts, especially when they're so old. Thanks!

[@marvinjno-baptiste726]

Been waiting for this for so long. Totally perplexed as to why it has taken so long for something so fundamental.

[@martinmanchev1276]

The new feature looks good. There is an old way to achieve the same: var tasks = Enumerable.Range(1, 5).Select(Calculate).Select(async i => Console.WriteLine(await i)); await Task.WhenAll(tasks); Here you reuse the defer idea of the LINQ

[@pawerobak6655]

I have used similar but with exception handling: var tasks = Enumerable.Range(1, 5).Select(Calculate).Select(i=>i.ContinueWith(i=>Console.WriteLine(i)));

[@andersborum9267]

It's great to see an continuous investment in all areas of the framework. Would like to see more focus on reactive extensions (RX) though, especially around async APIs.

[@obinnaokafor6252]

There is a going effort to improve RX

[@orterves]

What happens when an exception is thrown by one (or more) of the tasks?

[@vinydanylo]

I think an AggregateException would be thrown.

[@daravango]

My guess is an exception will be thrown when you `await` an individual task, and regarding the entire `await foreach` block, my guess would be: same behavior as `await`ing a `Task.WhenAll()`

[@victor1882]

I would expect that you get the exception when awaiting, or check and don't await if the task is faulted

[@Crozz22]

Exception won't be thrown until you await the task. So it would not be thrown by Task.WhenEach.

[@vothaison]

Well, that's what people will explore for themselves.

[@AlFasGD]

The video is very weirdly zoomed in some areas

[@urzaaaaa]

It's because the author is naked. He says it briefly right at the beginning of the video.

[@AlFasGD]

@@urzaaaaa what the fuck are you saying

[@felipe.raposo]

​@@urzaaaaa😂😂😂

[@sammtanX]

​@@urzaaaaathat's crazy

[@LC12345]

@@urzaaaaaYes, he certainly does!

[@tareksalha]

We are performing many of those independent tasks. Up until now, we have been using queues to solve the problem.

[@wojciechwilimowski985]

If you want to process tasks as they happen, you're two steps away from the point when it's serious enough to use System.Threading.Tasks.Dataflow

[@rmcgraw7943]

await foreach does this by default IAsyncEnum. U don’t need wheneach. the issue is locking, hence you need to customize your partitioner

[@dawizze1]

I hope to see some F# content on Dometrain one day. Love to learn how to leverage the language to write apis.

[@joepurdom2528]

Couple questions 1. When using WhenEach what thread does the Consle.WriteLine execute on? 2. Is any overhead introduced by using await task vs task.Result, given the fact that we know task.Status == RanToCompletion? Or maybe we don't know that, depends on how errors are handled. 3. Any difference in performance using WhenEach over await Task.WhenAll(tasks.Select(t => t.ContinueWith(async x => Console.WriteLine(await x)))); or is it just cleaner to look at?

[@mohamedeffat54]

seconding question 3, I'd assume since nick didn't mention it that ContinueWith in general won't give the same intended behavior but I want to actually know.

[@jonasgranlund4427]

I have a couple of places where I use Task.WhenAny together with large lists of tasks, so I iterate over a worklist of 100 task in parallel out the full list of 500-10000 total tasks and as soon as one of the 100 is ready I add a new one of the full list into my work-list and process til the full list is empty. I think that have worked quite well and a lot better than to try to do Task.WhenAll on 5000 tasks, even though it is a lot better now than on C# 5 when it went into Thread starvation Overload :) :)

[@realtimberstalker]

I feel like a simple solution to do this before .net 9 would have been to just wrap the task with another task that handles the result, and then awaitall those tasks instead.

[@simonwood2448]

Indeed. I fail to see the excitement here, it's a trivial thing to solve

[@realtimberstalker]

@@simonwood2448 This is syntactic sugar that is easier to use and reduces boilerplate. It’s certainly better. Im just saying I feel the original problem itself wasn’t some impossibly hard thing.

[@protox4]

That's not the same, though. That will process the results concurrently, while the new method processes sequentially.

[@TazG2000]

@@protox4 In the new method the tasks are still running concurrently, but the loop is responding to when each one completes. So this should, in theory, work the same way: await Task.WhenAll( tasks.Select(async t => { Console.WriteLine(await t); }));

[@TazG2000]

@@xybersurfer A couple points: 1. In practice, that probably wouldn't be true. If we're developing a UI where we need to avoid sending UI outputs concurrently, that would aready be taken care of by the synchronization context. The outputs would be queued to run on the same thread where we are using the await statement (the UI thread). 2. If we actually need to make sure these outputs _specifically_ aren't concurrent, all we need is a lock statement. We don't need to do any manual "ugly" implementations to make this work. To be clear, it's really nice that we can do this with "await foreach" now, but the point is most of these problems that used to be very complicated to solve are already quite simple now, so this new addition isn't really a game changer, it's just nice to have.

[@ricardoduarte442]

I would love to see a video of you looking at the implementation by microsoft and explaining why it is better :) Great vid as always Nick

[@rmcgraw7943]

I love LINQ, but be aware that it is implemented via extension methods, aka. anonymous methods, aka delegates, so they are allocationed on the heap, where inline fuctions go on the stack.

[@andrewallshouse4525]

Hey Nick love this!! Can you post the link to the Stephen Toub article?

[@nickchapsas]

devblogs.microsoft.com/pfxteam/processing-tasks-as-they-complete/

[@cemsayn9588]

Thank you Nick for sharing this great feature. I have implemented my own as many of us for a batch System IO operation. I was checking in a While loop with task has completed, cancelled or hasException properties. Then removing from batch operation array and adding new one to task array. I don't know why Microsoft wait for this feature so far.

[@timdoke]

I've been using the exact approach you showed with WhenAny for quite a while. It's good there's an easier way, and more performant way to do it though.

[@bgrant1512]

Wake me up when they make EF Core async friendly. That would make a huge difference.

[@lukeno4143]

why do you Console.WriteLine(await task); if the task was already completed before it gets to this statement? youre not (a)waiting for anything at this point. So whys it called await here? should it just be Console.WriteLine(task.Result)? and are the two identical at least since Result is already finished?

[@kaiserbergin]

I'm trying to think of where I would use this... In examples like this, I would usually write a method or a class that orchestrates the order of events. The signature would return a task that encapsulates the order of events. I don't doubt this has valid use cases, I'm just curious to see how people plan on using it and if there's something I'm missing.

[@danbopes]

This is a nice addition to the task echo system for sure!

[@thomassarmis]

Why not appending a .ContinueWith() and then do the WhenAll() ? would the end result be the same?

[@RuiSantos78]

Yeah, I normally do that way ...

[@oleksii766]

As an option we can use a some kind of the Pub/Sub approach to subscribe to the results as they appear

[@lordmetzgermeister]

I figured it would be solved by IAsyncEnumerable as that makes the most sense. Finally :)

[@haxi52]

Generally if I have a set of tasks I need chained, I'll wrap the call chain into another async method. So the caller really just needs to wait till everything is done.

[@tomtoups]

That's great if the T in Task[] are all the same. but if I'm calling multiple APIs using implicit parallelism, for example, and they all return a different types, then it doesn't really help me

[@warrenbuckley3267]

You could work around that by using Task. Then you could pattern match to figure out what model was returned.

[@tomtoups]

@@warrenbuckley3267 Yeah that's an idea. 👍

[@Cafe-O-Milk]

@@warrenbuckley3267 very costly

[@supreme_dev]

Late happy birthday Nick! keep up with the great work

[@JackBauerDev]

Wow that was way nicer than I expected

[@timjackmaster1385]

Very very nice feature. Has anyone benchmarked how much more efficient it is in comparison to the old approach?

[@naftalyweinberger7892]

nick i am a huge fan of the dometrain courses, but I would prefer, that the presenters should make prepared slides rather then drawing while talking, it slows things down and i prefer when they talk FAST. deep dive C# is GGOOOOODDDDD

[@stunna4498]

“Hello everybody my name is marioooo” sorry this was in my head when i heard the intro 😭😭😭😂

[@Cool-Game-Dev]

That is beautiful, thank you!

[@timur-mut]

Great feature, thanks for explanation.

[@noellysaght1007]

I achieved similar functionality using ActionBlocks from the TPL. I can see the benefits of this approach and how concise it is, but I think the functionality available in the TPL is under utilised when it comes to async processing.

[@rmcgraw7943]

IAsyncEnemerable where the source is yielded via a PLINQ. For or Parallel.for with custom partitioner

[@michaelsniknejs6326]

@3:43 "ton" although spelled with an "o" is actually pronounced "tun" (rhymes with "fun").

[@rogeriobarretto]

Do you have to await also the element of the task in the foreach loop? Will it trigger the task again, I assumed you would get the result straight back

[@sinan720]

Why did'nt you mention System.Linq.Async?

[@tahaali01]

So simple and clean, great!

[@amantinband]

Thank god we have Stephen. Btw I think the following PLINQ does the same: await ParralelEnumerable.Range(1, 5) .ForAll(I => Comsole.WriteLine(Calculate(I)))

[@nickchapsas]

I think the difference is that WhenEach will give you back the Task itself, not just the result so you have more flexibility on how you handle failure

[@user-dc9zo7ek5j]

@@nickchapsas I can't think of a use case where you want to continue the method without awaiting all tasks... additionally are 2 ways to do the thing you're describing already. 1. Creating a method that consumes the original method's value and add there the custom logic. 2. Use continuations. Here is a small program to demonstrate the second case: foreach (var t in Enumerable.Range(1, 6) .Select(async n => { await Task.Delay(new Random().Next(0, 10)); return n; }) .Select(t => t.ContinueWith(v => Console.WriteLine(v.Result)) .ToArray()) await t;

[@petrx-ray9766]

@@user-dc9zo7ek5j Absolutely agree! I've never heard about the problem which Nick described, as it is easily handled by continuations.

[@JohnWilliams-gy5yc]

Not exactly the same under the hood. I guess "parallel" is named because it "must" be paralleled. With it, you want to request some OS threads to work on your tasks, not "limited" in only the running thread concurrency realm.

[@bluecup25]

I just realized we're as far from 2012 as 2012 was from 2000

[@ThugLifeModafocah]

that's really good indeed.

[@derangedftw]

Wow, finally!

[@JeppeRaskDK]

Looks cool, but couldn't you just move the "Calculate()" call to an async method which awaits and does the post-processing and then finally Task.WhenAll on those? I rarely have a List of tasks that I don't control the creation of.

[@gronkymug2590]

I assume "await task" throws just for the specific task on exception, so we can nicely process errors of each task. I like it.

[@cdoubleplusgood]

"A sink a wait". I've seen it.

[@digibrett]

This is awesome!

[@7th_CAV_Trooper]

Why would you use a list instead of array in this sample?

[@j1shin]

Because of Remove()

[@zpa89]

To expand on the other reply, it only works because it removes items from the list and you cannot remove items from an array. You would have to splice/copy the items to a new array. List works similarly behind the scenes but Microsoft is much better at optimization than you or I.

[@d3tn3tracer]

Finally! :)

[@handlez411]

Very very cool! 🥳

[@xd-hood-classic]

Last time I had this problem, I just went with firing an event after task is done

[@MrOboema]

Fun fact: the existing solution in the Nito.AsyncEx package is lot more readable than the .NET 9 version 🤣

[@RealCheesyBread]

Wait so what's the difference between `Task.WhenEach()` and `tasks.ToAsyncEnumerable()`?

[@nanvlad]

WhenEach() is in BCL whereas ToAsyncEnumerable() is an reactive extension from System.Linq.Async

[@RealCheesyBread]

@@nanvlad But other than that, no difference?

[@nanvlad]

@@RealCheesyBread BCL should be more reliable and performant. Also it can be improved by Microsoft on the very low level.

[@MaximT]

For now you can use TPL Dataflow

[@krccmsitp2884]

That looks neat!

[@jell0goeswiggle]

Ive written that while loop before. Feels bad / looks ugly, but what are you going to do. I'm still enjoying great new things in .NET8, I dont need to be excited for 9 yet!

[@mirrorless_mirror]

Nice feature. But I will actually have to wait for a next LTS version of .NET (likely 10) to use it in the real life.

[@sunefred]

Very very elegant.

[@CezaryWalenciuk]

Ok what version of .NET 9 preview is this working. There is no "WhenEach" method

[@Crezber]

good question

[@montanomariano]

Awesome!

[@weicco]

If people just used async methods and, what is even more important, would use CancellationToken so that api calls could actually be cancelled!

[@As_Ss]

Its taken so long as this was non issue, can be done in multiple ways. Normally u would limit the Tasks logical threads for example with max degree of parallel cuz u dont want to run more than that, so a new task wont start until there is place for another anyway and when that happens the ended task can report. This function is just a cherry on the ice cake.

[@johncerpa3782]

Great video

[@mome3807]

Does WhenEach run in parallel? hard to tell the difference to the serial syntax foreach task in listOfTasks { await task }

[@RoBBed13]

This is nice

[@LogicException]

Wild effect in this video

[@kwibuske]

Is there a possibility to limit number of concurrent tasks it can await at once? Because if the input list is 1000 tasks long, spinning them all together will just create a bunch of overhead.

[@Biker322]

Probably use a SemaphoreSlin

[@MrBurikella]

Well, I think the easiest way would be to get a list of tasks which includes processing. Like `Enumerable.Range(1, 5).Select(async order => Console.WriteLine(await Calculate(order)))`. Clearly you can replace `Console.WriteLine` by anything else. I think it is much cleaner and easy to grasp.

[@protox4]

It's not quite the same, though. That will process concurrently, while the new method processes sequentially.

[@MrBurikella]

@@protox4 right, that requirement wasn't stated explicitly

[@zpa89]

​@@MrBurikellathat is literally the entire point of the video....

[@oct8bit]

This nice one

[@diegoronkkomaki6858]

Not completely happy about the need to await the task inside the Task.WhenEach loop. If the WhenEach is supposed to yield a completed task why not access the result immediately in the loop, why the need to await the task "again"? EDIT: Is it because the tasks can return different types of results?

[@scottbaldwin2477]

You need it for error handling. This pattern lets you await a task in a try/catch, deal with any exceptions, and then continue iterating.

[@jongeduard]

@scottbaldwin2477 Exactly, the place where the await is, there will happen the possible throws. Writing the entire thing myself while watching this video made that clear for me already. You can put a try block inside your await foreach block to handle each individual failed task. Which is the problem that you cannot with Task.WaitAll for example, which completely stops everything on the first exception.

[@diegoronkkomaki6858]

@@scottbaldwin2477 ah, of course. Makes sense.

[@diegoronkkomaki6858]

​@@scottbaldwin2477 Right, makes sense.

[@squaredcircle8833]

What about Parallel.ForEachAsync?

[@michaelakin766]

why do you have to do the await on the foreach and then on the task? It seems like the task is being called two times.

[@LordErnie]

Why not just use channels with separate sessions if you need resource syncing over single groups of tasks in a short process?

[@pagorbunov]

Because it would be overkill

[@F1nalspace]

I don't see any use-case for that feature. Just use a queue und do a while with await for each loop... you can even do a concurrent queue and do a parallel foreach... but still, what is the use-case for this? Process N-Items with the same type, waiting for each type until it its finished... thats like normal basic programming, not using any tasks at all... the point of tasks is do stuff in parallel - using the actual cores of a CPU, which people tend to forget that there is actual hardware running that code. Even in cases, where i do heavy data transformations and require multiple steps, even then i would not do it this way... maybe scrapping a website, parsing links... to prevent API blocking, due to too many request, would be the only use-case i could think of... Even multiple IO-access can still be done in parallel...

[@jorgepedraza1275]

🤔 interesting!

[@Grimlock1979]

Yeah, this feature was long overdue.

[@ValueLevit]

Am I missing something? tasksWithContinuation = taskList.Select(t => t.ContinueWith(delegate)).ToList();

[@ricardoduarte442]

You are passing a delegate, won't resolve in the main thread, I think that is the difference

[@ValueLevit]

@@ricardoduarte442 if there's such a requirement then the needed behavior can be configured in the ContinueWith method.

[@protox4]

That will process the results concurrently, while WhenEach processes sequentially.

[@ricardoduarte442]

@@protox4 Oh yeah true LOL

[@jesusdelarua5995]

I do not see WhenEach() available in my .NET 9 Preview version. Getting Compiler Error CS0117 Task' does not contain a definition for 'WhenEach' My version is 9.0.100-preview.2.24157.14 Ideas?

[@xMadClawx]

Same, I don’t even see it in the dotnet 9 preview on GitHub

[@romanhrytskiv8845]

Very nice

[@devwatch2359]

Best segue into a course advertisement ever! So smart, so smooth... I applaud you.

Or you could just have a function that does the Calculate(i) AND console.writeline ... WhenAll - that still does what it is suppose to do - waits for all of them.

[@felipesfaria]

This was my thought. It's what I would do in this situation.

[@JustaFrogger]

Great!🎉❤

[@andriiyustyk9378]

5:40 Why "tasks.Any()" instead of "tasks.Count > 0"?

[@zpa89]

Any seems a semantically easier to read. It is English not math. Plus no hard coded number. Technically slower, but modern computers can do billions to trillions of flops and the vast majority of all use cases will be bottlenecked by unmanaged resources like IO and network.

[@keyser456]

@@zpa89 Are we after performance or more readable code? Gotta pick one.

[@zpa89]

​@@keyser456 you are neglecting that modern dotnet puts some SERIOUS effort into optimizing linq expressions. In fact, I would bet the compiler optimizes away the more basic extensions entirely when the underlying runtime type is known.

[@keyser456]

@@zpa89 I'm neglecting nothing. There's an unhealthy obsession for "clean code", and it's to the point where people (by your own admission) are willing to trade off some performance. Will a tiny perf tradeoff be the deathblow in an app? Probably not. Is .Any() really that much better than Count > 0 from a readability standpoint? Definitely not. We're programming, not writing a book for kids.

[@zpa89]

@@keyser456 we are all humans. We are writing code that humans must maintain. As humans, we speak in human languages. Writing code in a more naturally human way makes code easier to read. When a human wants to decide whether they have to deal with something, they ask "are there any x left?" They don't say "is the count of x greater than zero?" Beyond that, the vast majority of software engineers are dealing with IO/network bound work. CPU cycles you save by hyper optimizing your code pale in comparison to the time you must spend waiting for unmanaged requests to return. I would love to say that one day you will learn all of this but I have interviewed hundreds of engineers from all over the world, I lead a team of 60+, and unfortunately it seems that tenure just does not make you a more intelligent engineer. If you aren't one of the bright ones now, you may never be.

[@the-avid-engineer]

It seems odd that it returns an async enumerable of tasks, and not the results. I’m sure there’s a good reason for that but.. yeah.. odd.

[@ErazerPT]

Maybe I'm just an old gezzer, but... if you want something done as they finish, why not pass them a callback? Yes, i know, context is gone, but if that is so paramount, is it not more of a "code smell" than anything else?

[@milkandhenny]

Callback hell, from nesting too many call backs is inevitable the moment a project becomes even the slight bit complex I'd assume. Being able to write I/O and other async tasks in a synchronous way just makes larger code bases more understandable for larger teams, or even yourself in the future

[@petrusion2827]

You could've already done that by calling Task.ContinueWith(...) on all of the tasks in the list, if you want to deal with it and the problems that arise. C# was one of the first languages to use async await so it makes sense that the standard library is going to use it where it can. After all, "Callbacks are the goto statement of our generation"

[@ErazerPT]

@@milkandhenny How does nesting come into play? Something like OrderComplete(int order){...} being passed to something like Task ProcessOrder(int order,Action callback) was all they needed to finish their work, no nesting here, it's fully local. By the time WhenAll() resolves, you know they all went through OrderComplete() and move on. Think you're conflating "work completion callback" with "forward return point callback". The first finishes work, but the calling site is still waiting. The second IS the "forward return" point because the calling site IS NOT waiting.

[@adambickford8720]

@@ErazerPT As long as none of your calls have dependencies, callbacks aren't terrible. As soon as you start having to coordinate them, callbacks are terrible.

[@ErazerPT]

@@adambickford8720 Once more, those are NOT the kind we are talking about. And yes, you're 100% right but Task's don't magically free you from it. If you're accessing shared resources, you'll still need some sort of await semaphore. Concurrency IS hell.

[@VandroiyIII]

Looks useful. Though I'm a bit torn about the ever increasing number of syntactic special cases in C#. The for, foreach, and now await foreach loops often take the place of higher-order functions, but proper higher-order functions are a bit crippled in their own special way. Doesn't this feel a bit like these projects where people only ever add features, but never refactor? A new programmer these days seems to be learning more and more cryptic rules for each real concept behind them.

[@chris-pee]

To be fair, "await foreach" (IAsyncEnumerable) was added in 2019 in C# 8.

[@Cool-Game-Dev]

C# has always supported backwards compatibility when possible.

[@matiascasag]

What about the library System.Threading.Tasks.Dataflow?

[@MEZOMEZO2011]

What is an actual use for this?

[@xelesarc1680]

Hi nick i need you help😢, i had some problem with parallel and async , i had 1000 batch data but need make it faster, i use parallel but got error in database why i cant crud if i use parallel , iam using sqlserver . If you read this maybe you can help me iam stuck 😢😢

[@luvincste]

thought this was a video about async2

[@protox4]

He did a separate video about that. And that's just an experiment currently, not officially in 9.

[@AlexanderBelikov]

Huh, so many TaskHelper.WhenAll will be retired soon..

[@Suriprofz]

Still feels hacky when used to go or rust channels

[@Doggettxx]

c# has channels as well, not sure why he didn't talk about it since they're much more useful in most cases

[@eugenes9602]

Linq.Async definitely looks better than this

[@thedarkside0007]

this just like select in golang

[@LE8271]

Well Nick, after buying 12 of your courses you could have given me that one for free... :/

[@nickchapsas]

Email me

[@harcio]

What is the difference between this and Parallel.ForEachAsync?