4 ms·

async/await are great: * pull based -> you don't need to worry so much about rate-limiting like you do with events * works well when needing to pull over slow

async/await are great: * pull based -> you don't need to worry so much about rate-limiting like you do with events * works well when needing to pull over slow communications (serial, remotes)

pjmlp 4y ago
Until one needs to integrate a non async aware library and then is Task.Run() all over the place.
- MrGilbert 4y ago
  A thin abstraction layer could help.
  - pjmlp 4y ago
    It hardly works well across all use cases and consulting projects.
- martinald 4y ago
  Pretty rare these days though.
  - pjmlp 4y ago
    These days there are still ton of libraries that are yet to run on .NET Core reboot, let alone fix their async/await story. Welcome to Python 2 / Python 3 version of .NET evolution.
    - martinald 4y ago
      Hmm not sure it's really anything as bad as Python2/3. I haven't came across a library that doesn't support netstandard (and 99% of those will do async/await) in a long time now. There are a lot of libs that haven't been updated for years and therefore don't support netstandard. But you probably don't want to be using them outside of very specific use cases given they are likely to be insecure by now. There definitely isn't a 'we're holding on to netframework' vibe in dotnet, like there was for python2.
      - pjmlp 4y ago
        Try to do enterprise consultancy and there will be plenty to care of. To the point that some companies rather spend their budgets into full rewrites into other stocks, or acquisitions, instead of porting into .NET. See Sitecore, as an example of what was once a key player in .NET CMS enterprise space, now focusing into other stacks.
        james-skemp 4y ago
        Used Sitecore at my last job, so I'm curious what they're migrating to. All I could find mentioned .NET Core. Do you have a link that covers what they're moving to?
        pjmlp 4y ago
        Kind of, https://www.sitecore.com/landing/uk/2023/the-future-is-composable https://www.sitecore.com/landing/uk/2023/the-future-is-compo... Most of the new acquisitions are based on Java, with exception of Order Cloud and Content Hub. .NET Core is available for XP headless rendering SDK, however it is NextJS/JSS that are getting the spotlight and there is plenty of DIY if you will go down .NET Core, specially after the cooperation agreement with Vercel. Classical XP is stuck on .NET Framework and XM Cloud customisation points favours WebHooks instead of writing .NET code. CDP, Search, Send are low code tooling, only exposing Web APIs, and JavaScript. Content Hub does allow for some use of C# in scripting, but it is mostly about Webhooks as well.
        pjmlp 4y ago
        Since I cannot edit, this is the .NET Core rendering SDK https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-headless-development/sitecore-asp-net-rendering-sdk.html https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-he... However as you can see, XM Cloud clearly favours JavaScript, specially in the components that replace content editor and page graphical editing, https://doc.sitecore.com/xmc/en/developers/xm-cloud/sitecore-experience-manager-cloud.html https://doc.sitecore.com/xmc/en/developers/xm-cloud/sitecore... And then check the acquisitions, https://doc.sitecore.com/ https://doc.sitecore.com/
- avsteele 4y ago
  I don't see how this is a criticism of async. You have two options: 1) Use Task.Run and await its result whenever you need it. 2) make a blocking call; same as if async wasn't available. How does having option 1 make the situation worse?
  - pjmlp 4y ago
    Colorful coding, to the point David Fowler has been looking how to improve the status quo.
- becquerel 4y ago
  You can rewrite all the old async patterns into using awaitable Tasks. I've done it.
  - pjmlp 4y ago
    Me too, when code ownership allows it, and someone pays for my time doing so.
ziml77 4y ago
It's a massive improvement over callbacks when using an event loop model too. I've worked with code that has an insane amount of nesting because it was written before async/await and instead had to pass in a callback every time it went off to do an asynchronous operation. It made the code very hard to read and it complicated exception handling, resource lifetime management, and even simply iterating over an input. With async/await the code ends up structured the same as if the operations were synchronous. It's much easier to follow and modify.

async/await are great: * pull based -> you don't need to worry so much about rate-limiting like you do with events * works well when needing to pull over slow communications (serial, remotes)

pjmlp 4y ago

Until one needs to integrate a non async aware library and then is Task.Run() all over the place.

MrGilbert 4y ago
A thin abstraction layer could help.
- pjmlp 4y ago
  It hardly works well across all use cases and consulting projects.
martinald 4y ago
Pretty rare these days though.
- pjmlp 4y ago
  These days there are still ton of libraries that are yet to run on .NET Core reboot, let alone fix their async/await story. Welcome to Python 2 / Python 3 version of .NET evolution.
  - martinald 4y ago
    Hmm not sure it's really anything as bad as Python2/3. I haven't came across a library that doesn't support netstandard (and 99% of those will do async/await) in a long time now. There are a lot of libs that haven't been updated for years and therefore don't support netstandard. But you probably don't want to be using them outside of very specific use cases given they are likely to be insecure by now. There definitely isn't a 'we're holding on to netframework' vibe in dotnet, like there was for python2.
    - pjmlp 4y ago
      Try to do enterprise consultancy and there will be plenty to care of. To the point that some companies rather spend their budgets into full rewrites into other stocks, or acquisitions, instead of porting into .NET. See Sitecore, as an example of what was once a key player in .NET CMS enterprise space, now focusing into other stacks.
      - james-skemp 4y ago
        Used Sitecore at my last job, so I'm curious what they're migrating to. All I could find mentioned .NET Core. Do you have a link that covers what they're moving to?
        pjmlp 4y ago
        Kind of, https://www.sitecore.com/landing/uk/2023/the-future-is-composable https://www.sitecore.com/landing/uk/2023/the-future-is-compo... Most of the new acquisitions are based on Java, with exception of Order Cloud and Content Hub. .NET Core is available for XP headless rendering SDK, however it is NextJS/JSS that are getting the spotlight and there is plenty of DIY if you will go down .NET Core, specially after the cooperation agreement with Vercel. Classical XP is stuck on .NET Framework and XM Cloud customisation points favours WebHooks instead of writing .NET code. CDP, Search, Send are low code tooling, only exposing Web APIs, and JavaScript. Content Hub does allow for some use of C# in scripting, but it is mostly about Webhooks as well.
        pjmlp 4y ago
        Since I cannot edit, this is the .NET Core rendering SDK https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-headless-development/sitecore-asp-net-rendering-sdk.html https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-he... However as you can see, XM Cloud clearly favours JavaScript, specially in the components that replace content editor and page graphical editing, https://doc.sitecore.com/xmc/en/developers/xm-cloud/sitecore-experience-manager-cloud.html https://doc.sitecore.com/xmc/en/developers/xm-cloud/sitecore... And then check the acquisitions, https://doc.sitecore.com/ https://doc.sitecore.com/
avsteele 4y ago
I don't see how this is a criticism of async. You have two options: 1) Use Task.Run and await its result whenever you need it. 2) make a blocking call; same as if async wasn't available. How does having option 1 make the situation worse?
- pjmlp 4y ago
  Colorful coding, to the point David Fowler has been looking how to improve the status quo.
becquerel 4y ago
You can rewrite all the old async patterns into using awaitable Tasks. I've done it.
- pjmlp 4y ago
  Me too, when code ownership allows it, and someone pays for my time doing so.

ziml77 4y ago

It's a massive improvement over callbacks when using an event loop model too. I've worked with code that has an insane amount of nesting because it was written before async/await and instead had to pass in a callback every time it went off to do an asynchronous operation. It made the code very hard to read and it complicated exception handling, resource lifetime management, and even simply iterating over an input. With async/await the code ends up structured the same as if the operations were synchronous. It's much easier to follow and modify.