4 ms·

async/await in .NET is actually good because they added async equivalent APIs to nearly all blocking operations. There's also always (from what I've seen) an op

async/await in .NET is actually good because they added async equivalent APIs to nearly all blocking operations. There's also always (from what I've seen) an optional cancellation token parameter that allows an easy mechanism to alleviate backpressure. Need an easy way to cancel 100 async requests? Easy, just pass in a cancellation token and cancel it when needed. All the requests will throw an OperationCanceledException which can be cleanly handled. I haven't seen anything this nice in javascript or python.

lazulicurio 7y ago
> async/await in .NET is actually good because they added async equivalent APIs to nearly all blocking operations I mean... I get it---it's great how Microsoft put in an effort to add async equivalents to most of your standard operations. But my complaint is about how almost all of those async methods are built upon Task/Task<T> (which, IMO, is a flawed foundation). > There's also always (from what I've seen) an optional cancellation token parameter that allows an easy mechanism to alleviate backpressure. > Need an easy way to cancel 100 async requests? Easy, just pass in a cancellation token and cancel it when needed. All the requests will throw an OperationCanceledException which can be cleanly handled. No significant disagreement from me there. It is nice that most core async methods support (or try to support) cancellation.
- cies 7y ago
  > But my complaint is about how almost all of those async methods are built upon Task/Task<T> (which, IMO, is a flawed foundation). Do you know any not-flawed implementation?
  - lazulicurio 7y ago
    Implementations as in .Net implementations? Or implementations as in other languages' implementations? As far as .Net goes, I've not looked around. I feel like it would be somewhat of a fool's errand to develop an alternative async/await implementation because almost all of the core APIs use Task/Task<T>, so you'd either be using Task/Task<T> anyway or re-producing a lot of APIs.
    - WorldMaker 7y ago
      async/await itself is "subtly duck typed" in most of the .NET compilers along with other bits of compiler work (among other examples IEnumerable/IEnumerable<T> in C#'s foreach is also subtly duck typed and not dependent on the specific BCL interfaces, though almost no one would use bespoke interfaces), which is how .NET Core was relatively easily able to add ValueTask/ValueTask<T> and a lot of .NET Core APIs have been slowly migrating to ValueTask/ValueTask<T> without much compatibility breaking trouble.
- Const-me 7y ago
  > almost all of those async methods are built upon Task/Task<T> (which, IMO, is a flawed foundation) I like them, very flexible. It’s easy to implement these tasks on top of pretty much anything. Here’s how I have implemented back pressure when I needed something similar: https://github.com/Const-me/pCloud/blob/master/pCloudCore/Utils/TaskQueue.cs https://github.com/Const-me/pCloud/blob/master/pCloudCore/Ut... That class is very generic, knows nothing about the nature of the tasks, yet it’s able to do the right thing. Specifically, it limits count of pending tasks to a small number (8 by default), when exceeded the `post` method will start to “block” in the async way, that’s why it returns `Task<Task<TResult>>` instead of just `Task<TResult>`.

lazulicurio 7y ago

> async/await in .NET is actually good because they added async equivalent APIs to nearly all blocking operations I mean... I get it---it's great how Microsoft put in an effort to add async equivalents to most of your standard operations. But my complaint is about how almost all of those async methods are built upon Task/Task<T> (which, IMO, is a flawed foundation). > There's also always (from what I've seen) an optional cancellation token parameter that allows an easy mechanism to alleviate backpressure. > Need an easy way to cancel 100 async requests? Easy, just pass in a cancellation token and cancel it when needed. All the requests will throw an OperationCanceledException which can be cleanly handled. No significant disagreement from me there. It is nice that most core async methods support (or try to support) cancellation.

cies 7y ago
> But my complaint is about how almost all of those async methods are built upon Task/Task<T> (which, IMO, is a flawed foundation). Do you know any not-flawed implementation?
- lazulicurio 7y ago
  Implementations as in .Net implementations? Or implementations as in other languages' implementations? As far as .Net goes, I've not looked around. I feel like it would be somewhat of a fool's errand to develop an alternative async/await implementation because almost all of the core APIs use Task/Task<T>, so you'd either be using Task/Task<T> anyway or re-producing a lot of APIs.
  - WorldMaker 7y ago
    async/await itself is "subtly duck typed" in most of the .NET compilers along with other bits of compiler work (among other examples IEnumerable/IEnumerable<T> in C#'s foreach is also subtly duck typed and not dependent on the specific BCL interfaces, though almost no one would use bespoke interfaces), which is how .NET Core was relatively easily able to add ValueTask/ValueTask<T> and a lot of .NET Core APIs have been slowly migrating to ValueTask/ValueTask<T> without much compatibility breaking trouble.
Const-me 7y ago
> almost all of those async methods are built upon Task/Task<T> (which, IMO, is a flawed foundation) I like them, very flexible. It’s easy to implement these tasks on top of pretty much anything. Here’s how I have implemented back pressure when I needed something similar: https://github.com/Const-me/pCloud/blob/master/pCloudCore/Utils/TaskQueue.cs https://github.com/Const-me/pCloud/blob/master/pCloudCore/Ut... That class is very generic, knows nothing about the nature of the tasks, yet it’s able to do the right thing. Specifically, it limits count of pending tasks to a small number (8 by default), when exceeded the `post` method will start to “block” in the async way, that’s why it returns `Task<Task<TResult>>` instead of just `Task<TResult>`.