4 ms·

One under-appreciated aspect of async is that it gives you a nice API for composing operations. Yes, async can be harder to introspect, especially with a debug

One under-appreciated aspect of async is that it gives you a nice API for composing operations. Yes, async can be harder to introspect, especially with a debugger, and it introduces function colouring. But in return it gives you a clear type-system level indication that computations are not pure and don't resolve immediately. You also get simple tools to combine, map/modify, join and potentially cancel individual asynchronous tasks. You can in theory get a similar API with threads and/or channels, but I've never seen anything that was anywhere as convenient as async.

moonchrome 4y ago
>But in return it gives you a clear type-system level indication that computations are not pure and don't resolve immediately. Is that actually useful ? You can have "BlockingLongCall()" without async and it could block your thread from progressing for minutes - or you could have "await FunctionThatResumesImmediatelyOnTheCaller()" and it doesn't even context switch. > You can in theory get a similar API with threads and/or channels, but I've never seen anything that was anywhere as convenient as async. I mean you can use the exact same interfaces in .NET and threat tasks as Threads with a custom scheduler implementation (that fires up a thread for each Task you start). And Tasks in .NET implement blocking operations as well as async ones.
- piaste 4y ago
  > Is that actually useful ? You can have "BlockingLongCall()" without async and it could block your thread from progressing for minutes - or you could have "await FunctionThatResumesImmediatelyOnTheCaller()" and it doesn't even context switch. Very much so. Async is - I would guess 95% of the time - a proxy for IO operations. Error handling is different: a pure function can and should be bug-free, while an IO function can always crash due to external factors. Performance tuning is different: a slow pure function needs optimization, parallelization, and worst case a faster CPU, while a slow async function usually needs you to dive into the plumbing part of your code to see if you're using an API wrong or something like that.
  - moonchrome 4y ago
    But in imperative OO style you're touching IO all over the place - this is why people complain about Task/Promise proliferation. And especially if you have something like interfaces where some implementation could require IO while other might not. In my experience you can't really use it to narrow down anything.

moonchrome 4y ago

>But in return it gives you a clear type-system level indication that computations are not pure and don't resolve immediately. Is that actually useful ? You can have "BlockingLongCall()" without async and it could block your thread from progressing for minutes - or you could have "await FunctionThatResumesImmediatelyOnTheCaller()" and it doesn't even context switch. > You can in theory get a similar API with threads and/or channels, but I've never seen anything that was anywhere as convenient as async. I mean you can use the exact same interfaces in .NET and threat tasks as Threads with a custom scheduler implementation (that fires up a thread for each Task you start). And Tasks in .NET implement blocking operations as well as async ones.

piaste 4y ago
> Is that actually useful ? You can have "BlockingLongCall()" without async and it could block your thread from progressing for minutes - or you could have "await FunctionThatResumesImmediatelyOnTheCaller()" and it doesn't even context switch. Very much so. Async is - I would guess 95% of the time - a proxy for IO operations. Error handling is different: a pure function can and should be bug-free, while an IO function can always crash due to external factors. Performance tuning is different: a slow pure function needs optimization, parallelization, and worst case a faster CPU, while a slow async function usually needs you to dive into the plumbing part of your code to see if you're using an API wrong or something like that.
- moonchrome 4y ago
  But in imperative OO style you're touching IO all over the place - this is why people complain about Task/Promise proliferation. And especially if you have something like interfaces where some implementation could require IO while other might not. In my experience you can't really use it to narrow down anything.