Lovely feature BTW that zoomed middle region messes with my brain

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.

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

@sinan720

2 ай бұрын

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

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

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

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

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

So simple and clean, great!

Late happy birthday Nick! keep up with the great work

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

2 ай бұрын

There is a going effort to improve RX

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

@vinydanylo

2 ай бұрын

I think an AggregateException would be thrown.

@daravango

2 ай бұрын

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

2 ай бұрын

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

@Crozz22

2 ай бұрын

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

@vothaison

2 ай бұрын

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

That is beautiful, thank you!

Great feature, thanks for explanation.

Wow that was way nicer than I expected

The video is very weirdly zoomed in some areas

@urzalukaskubicek9690

2 ай бұрын

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

@AlFasGD

2 ай бұрын

@@urzalukaskubicek9690 what the fuck are you saying

@felipe.raposo

2 ай бұрын

​@@urzalukaskubicek9690😂😂😂

@sammtanX

2 ай бұрын

​@@urzalukaskubicek9690that's crazy

@LC12345

2 ай бұрын

@@urzalukaskubicek9690Yes, he certainly does!

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

2 ай бұрын

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.

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.

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

@nickchapsas

2 ай бұрын

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

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

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

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

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

That looks neat!

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

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.

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

2 ай бұрын

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

2 ай бұрын

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

2 ай бұрын

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

@JohnWilliams-gy5yc

2 ай бұрын

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.

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

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.

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

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

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.

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

@j1shin

2 ай бұрын

Because of Remove()

@zpa89

2 ай бұрын

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.

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.

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

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

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.

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

2 ай бұрын

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

@tomtoups

2 ай бұрын

@@warrenbuckley3267 Yeah that's an idea. 👍

@Cafe-O-Milk

2 ай бұрын

@@warrenbuckley3267 very costly

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

2 ай бұрын

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

@realtimberstalker

2 ай бұрын

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

2 ай бұрын

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

@TazG2000

2 ай бұрын

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

2 ай бұрын

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

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

that's really good indeed.

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

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

Great video

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

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.

Wow, finally!

This is awesome!

Very very elegant.

Very nice

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

2 ай бұрын

Probably use a SemaphoreSlin

Great!🎉❤

This nice one

🤔 interesting!

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

Very very cool! 🥳

Been using Stephen Toub's Interleaved method for the longest time. Nice to finally see this as a Task extension method.

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

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

2 ай бұрын

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

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

@pagorbunov

2 ай бұрын

Because it would be overkill

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

@Crezber

2 ай бұрын

good question

For now you can use TPL Dataflow

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

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

@nanvlad

2 ай бұрын

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

@RealCheesyBread

2 ай бұрын

@@nanvlad But other than that, no difference?

@nanvlad

2 ай бұрын

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

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

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

This is nice

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

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

2 ай бұрын

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

2 ай бұрын

@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

2 ай бұрын

@@scottbaldwin2477 ah, of course. Makes sense.

@diegoronkkomaki6858

2 ай бұрын

​@@scottbaldwin2477 Right, makes sense.

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

Awesome!

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.

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!

Wild effect in this video

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

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.

Finally! :)

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

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.

Yeah, this feature was long overdue.

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

@zpa89

2 ай бұрын

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

2 ай бұрын

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

@zpa89

2 ай бұрын

​@@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

2 ай бұрын

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

2 ай бұрын

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

What is an actual use for this?

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

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

2 ай бұрын

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

2 ай бұрын

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

2 ай бұрын

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

2 ай бұрын

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

2 ай бұрын

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

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.

thought this was a video about async2

@protox4

2 ай бұрын

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

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

2 ай бұрын

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

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

@ricardoduarte442

2 ай бұрын

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

@ValueLevit

2 ай бұрын

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

@protox4

2 ай бұрын

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

@ricardoduarte442

2 ай бұрын

@@protox4 Oh yeah true LOL

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

2 ай бұрын

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

@MrBurikella

2 ай бұрын

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

@zpa89

2 ай бұрын

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

this just like select in golang

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

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

2 ай бұрын

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

@C00l-Game-Dev

2 ай бұрын

C# has always supported backwards compatibility when possible.

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

Why dont just use callbacks? Seems like a problem out of nowhere

It will be interesting to know what happens in race condition, if two tasks getting completed at same time, will this handle out of box or something that needs a special handling

@pagorbunov

2 ай бұрын

Since the order is not guaranteed I don't think it's an issue at all

Something is wrong with your video as we can't see all the information. Seems like the encoding had some corrupted data.

This is great! But before instead of playing around with a list I would most probably just create a new method that would invoke both the original task and do the result processing and just run this one with Task.WhenAll. The list approach feels very engineery.

What is the difference between this and Parallel.ForEachAsync?

You said "no lists involved" when there is obviously a list involved. I understand enough that it could be any sort of IAsyncEnumerable but your code sample still used a list.

@ricardoduarte442

2 ай бұрын

I think is more about the allocation, is like using IEnumerable with ApplicationDbContext from EF, you are only bringing items to memory when u need them, in this case u are just getting the task pointers, not a list that have tasks (I AM NOT 100% SURE ON THIS, actually would like to see a response from Nick on this)

Similar to JavaScript

I don't understand what was actually hard in implenting this. The examples also makes no sense. Especially the 'while' loop - what is the purpose of this? Can't you just store 'WhenAll()' in a variable and check 'if(all.isCompleted) tasks.Clear()' after 'await WaitAny(task)'? I can also think of many other, better solutions to do the same thing. It seems you picked the worst possible implementation just for the contrast... PS. Sorry for my spellings I'm writing this on my phone.

@pagorbunov

2 ай бұрын

That is why that new API was added. Instead of doing a common thing in thousand ways there would be official and most efficient one.