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/courses/
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/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

Пікірлер: 212

  • @tehsimo
    @tehsimo2 ай бұрын

    Lovely feature BTW that zoomed middle region messes with my brain

  • @DredTather
    @DredTather2 ай бұрын

    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
    @yuGesreveR2 ай бұрын

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

  • @sinan720

    @sinan720

    2 ай бұрын

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

  • @Ilix42
    @Ilix422 ай бұрын

    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
    @marvinjno-baptiste7262 ай бұрын

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

  • @orterves
    @orterves2 ай бұрын

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

  • @vinydanylo

    @vinydanylo

    2 ай бұрын

    I think an AggregateException would be thrown.

  • @daravango

    @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

    @victor1882

    2 ай бұрын

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

  • @Crozz22

    @Crozz22

    2 ай бұрын

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

  • @vothaison

    @vothaison

    2 ай бұрын

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

  • @devwatch2359
    @devwatch23592 ай бұрын

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

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

  • @AlFasGD
    @AlFasGD2 ай бұрын

    The video is very weirdly zoomed in some areas

  • @urzalukaskubicek9690

    @urzalukaskubicek9690

    2 ай бұрын

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

  • @AlFasGD

    @AlFasGD

    2 ай бұрын

    @@urzalukaskubicek9690 what the fuck are you saying

  • @felipe.raposo

    @felipe.raposo

    2 ай бұрын

    ​@@urzalukaskubicek9690😂😂😂

  • @sammtanX

    @sammtanX

    2 ай бұрын

    ​@@urzalukaskubicek9690that's crazy

  • @LC12345

    @LC12345

    2 ай бұрын

    @@urzalukaskubicek9690Yes, he certainly does!

  • @joepurdom2528
    @joepurdom25282 ай бұрын

    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

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

  • @tahaali01
    @tahaali012 ай бұрын

    So simple and clean, great!

  • @supreme_dev
    @supreme_dev2 ай бұрын

    Late happy birthday Nick! keep up with the great work

  • @C00l-Game-Dev
    @C00l-Game-Dev2 ай бұрын

    That is beautiful, thank you!

  • @andersborum9267
    @andersborum92672 ай бұрын

    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

    @obinnaokafor6252

    2 ай бұрын

    There is a going effort to improve RX

  • @timur-mut
    @timur-mut2 ай бұрын

    Great feature, thanks for explanation.

  • @tareksalha
    @tareksalha2 ай бұрын

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

  • @JackBauerDev
    @JackBauerDev2 ай бұрын

    Wow that was way nicer than I expected

  • @cemsayn9588
    @cemsayn95882 ай бұрын

    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.

  • @dawizze1
    @dawizze12 ай бұрын

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

  • @oleksii766
    @oleksii7662 ай бұрын

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

  • @rmcgraw7943
    @rmcgraw794313 күн бұрын

    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.

  • @wojciechwilimowski985
    @wojciechwilimowski9852 ай бұрын

    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

  • @danbopes
    @danbopes2 ай бұрын

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

  • @andrewallshouse4525
    @andrewallshouse45252 ай бұрын

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

  • @nickchapsas

    @nickchapsas

    2 ай бұрын

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

  • @ricardoduarte442
    @ricardoduarte4422 ай бұрын

    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
    @rmcgraw794313 күн бұрын

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

  • @xybersurfer
    @xybersurfer2 ай бұрын

    this is a really cool feature, that i didn't realize i needed

  • @timjackmaster1385
    @timjackmaster13852 ай бұрын

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

  • @krccmsitp2884
    @krccmsitp28842 ай бұрын

    That looks neat!

  • @rogeriobarretto
    @rogeriobarretto13 күн бұрын

    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

  • @kaiserbergin
    @kaiserbergin2 ай бұрын

    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.

  • @thomassarmis
    @thomassarmis2 ай бұрын

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

  • @timdoke
    @timdoke2 ай бұрын

    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.

  • @rmcgraw7943
    @rmcgraw794313 күн бұрын

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

  • @haxi52
    @haxi522 ай бұрын

    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.

  • @noellysaght1007
    @noellysaght10072 ай бұрын

    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.

  • @gronkymug2590
    @gronkymug25902 ай бұрын

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

  • @derangedftw
    @derangedftw2 ай бұрын

    Wow, finally!

  • @amantinband
    @amantinband2 ай бұрын

    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

    @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

    @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

    @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

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

  • @digibrett
    @digibrett2 ай бұрын

    This is awesome!

  • @mome3807
    @mome38072 ай бұрын

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

  • @handlez411
    @handlez4112 ай бұрын

    Very very cool! 🥳

  • @michaelakin766
    @michaelakin7662 ай бұрын

    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.

  • @johncerpa3782
    @johncerpa37822 ай бұрын

    Great video

  • @oct8bit
    @oct8bit2 ай бұрын

    This nice one

  • @ThugLifeModafocah
    @ThugLifeModafocah2 ай бұрын

    that's really good indeed.

  • @realtimberstalker
    @realtimberstalker2 ай бұрын

    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

    @simonwood2448

    2 ай бұрын

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

  • @realtimberstalker

    @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

    @protox4

    2 ай бұрын

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

  • @TazG2000

    @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); }));

  • @xybersurfer

    @xybersurfer

    2 ай бұрын

    @@TazG2000 that's still concurrent, because they are not sequentially writing to the console. each task writes as soon as it is finished, but they could be finished at the same time. you could probably make all tasks write sequentially with some kind of mutex like SemaphoreSlim, but that gets uglier

  • @d3tn3tracer
    @d3tn3tracer2 ай бұрын

    Finally! :)

  • @michaelsniknejs6326
    @michaelsniknejs63262 ай бұрын

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

  • @RoBBed13
    @RoBBed13Ай бұрын

    This is nice

  • @lordmetzgermeister
    @lordmetzgermeister2 ай бұрын

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

  • @montanomariano
    @montanomariano2 ай бұрын

    Awesome!

  • @JustaFrogger
    @JustaFrogger2 ай бұрын

    Great!🎉❤

  • @romanhrytskiv8845
    @romanhrytskiv88452 ай бұрын

    Very nice

  • @tomtoups
    @tomtoups2 ай бұрын

    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

    @warrenbuckley3267

    2 ай бұрын

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

  • @tomtoups

    @tomtoups

    2 ай бұрын

    @@warrenbuckley3267 Yeah that's an idea. 👍

  • @Cafe-O-Milk

    @Cafe-O-Milk

    2 ай бұрын

    @@warrenbuckley3267 very costly

  • @sunefred
    @sunefred2 ай бұрын

    Very very elegant.

  • @7th_CAV_Trooper
    @7th_CAV_Trooper2 ай бұрын

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

  • @j1shin

    @j1shin

    2 ай бұрын

    Because of Remove()

  • @zpa89

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

  • @cdoubleplusgood
    @cdoubleplusgood2 ай бұрын

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

  • @sinan720
    @sinan7202 ай бұрын

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

  • @bgrant1512
    @bgrant15122 ай бұрын

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

  • @jorgepedraza1275
    @jorgepedraza12752 ай бұрын

    🤔 interesting!

  • @JeppeRaskDK
    @JeppeRaskDK2 ай бұрын

    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.

  • @MaximT
    @MaximT29 күн бұрын

    For now you can use TPL Dataflow

  • @xd-hood-classic
    @xd-hood-classicАй бұрын

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

  • @daddy2claire
    @daddy2claire2 ай бұрын

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

  • @jesusdelarua5995
    @jesusdelarua59952 ай бұрын

    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

    @xMadClawx

    2 ай бұрын

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

  • @CezaryWalenciuk
    @CezaryWalenciuk2 ай бұрын

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

  • @Crezber

    @Crezber

    2 ай бұрын

    good question

  • @jell0goeswiggle
    @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!

  • @kwibuske
    @kwibuske2 ай бұрын

    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

    @Biker322

    2 ай бұрын

    Probably use a SemaphoreSlin

  • @RealCheesyBread
    @RealCheesyBread2 ай бұрын

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

  • @nanvlad

    @nanvlad

    2 ай бұрын

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

  • @RealCheesyBread

    @RealCheesyBread

    2 ай бұрын

    @@nanvlad But other than that, no difference?

  • @nanvlad

    @nanvlad

    2 ай бұрын

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

  • @xelesarc1680
    @xelesarc16802 ай бұрын

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

  • @LogicException
    @LogicException2 ай бұрын

    Wild effect in this video

  • @bluecup25
    @bluecup252 ай бұрын

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

  • @stunna4498
    @stunna44982 ай бұрын

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

  • @LordErnie
    @LordErnie2 ай бұрын

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

  • @pagorbunov

    @pagorbunov

    2 ай бұрын

    Because it would be overkill

  • @diegoronkkomaki6858
    @diegoronkkomaki68582 ай бұрын

    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

    @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

    @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

    @diegoronkkomaki6858

    2 ай бұрын

    @@scottbaldwin2477 ah, of course. Makes sense.

  • @diegoronkkomaki6858

    @diegoronkkomaki6858

    2 ай бұрын

    ​@@scottbaldwin2477 Right, makes sense.

  • @ivanp_personal
    @ivanp_personal2 ай бұрын

    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.

  • @gbjbaanb
    @gbjbaanb2 ай бұрын

    The only feature I've been waiting years for is to safely run these await async methods from a sync method. Damn mess Microsoft created.

  • @Grimlock1979
    @Grimlock19792 ай бұрын

    Yeah, this feature was long overdue.

  • @naftalyweinberger7892
    @naftalyweinberger78922 ай бұрын

    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

  • 2 ай бұрын

    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

    @felipesfaria

    2 ай бұрын

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

  • @VandroiyIII
    @VandroiyIII2 ай бұрын

    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

    @chris-pee

    2 ай бұрын

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

  • @C00l-Game-Dev

    @C00l-Game-Dev

    2 ай бұрын

    C# has always supported backwards compatibility when possible.

  • @F1nalspace
    @F1nalspace2 ай бұрын

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

  • @MEZOMEZO2011
    @MEZOMEZO2011Ай бұрын

    What is an actual use for this?

  • @ErazerPT
    @ErazerPT2 ай бұрын

    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

    @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

    @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

    @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

    @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

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

  • @As_Ss
    @As_Ss2 ай бұрын

    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.

  • @andriiyustyk9378
    @andriiyustyk93782 ай бұрын

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

  • @zpa89

    @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

    @keyser456

    2 ай бұрын

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

  • @zpa89

    @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

    @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

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

  • @ValueLevit
    @ValueLevit2 ай бұрын

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

  • @ricardoduarte442

    @ricardoduarte442

    2 ай бұрын

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

  • @ValueLevit

    @ValueLevit

    2 ай бұрын

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

  • @protox4

    @protox4

    2 ай бұрын

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

  • @ricardoduarte442

    @ricardoduarte442

    2 ай бұрын

    @@protox4 Oh yeah true LOL

  • @the-avid-engineer
    @the-avid-engineer2 ай бұрын

    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.

  • @MrBurikella
    @MrBurikella2 ай бұрын

    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

    @protox4

    2 ай бұрын

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

  • @MrBurikella

    @MrBurikella

    2 ай бұрын

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

  • @zpa89

    @zpa89

    2 ай бұрын

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

  • @weicco
    @weicco2 ай бұрын

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

  • @luvincste
    @luvincste2 ай бұрын

    thought this was a video about async2

  • @protox4

    @protox4

    2 ай бұрын

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

  • @thedarkside0007
    @thedarkside00072 ай бұрын

    this just like select in golang

  • @gauravmanchanda4658
    @gauravmanchanda46582 ай бұрын

    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

    @pagorbunov

    2 ай бұрын

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

  • @mvaddlu
    @mvaddlu2 ай бұрын

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

  • @Matlauk
    @Matlauk2 ай бұрын

    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

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

  • @MrKulkoski
    @MrKulkoski2 ай бұрын

    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.

  • @harcio
    @harcio2 ай бұрын

    What is the difference between this and Parallel.ForEachAsync?

  • @Suriprofz
    @SuriprofzАй бұрын

    Still feels hacky when used to go or rust channels

  • @Doggettxx

    @Doggettxx

    Ай бұрын

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

  • @bogdan.p
    @bogdan.p2 ай бұрын

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