3 ms·

It's better but it suffers from the same poison aspect all async/await implementations do. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-fun

It's better but it suffers from the same poison aspect all async/await implementations do. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

steveklabnik 7y ago
Yes. Engineering is all about tradeoffs. This is a downside, but it is made up for by all the upsides.
naasking 7y ago
Can't say I find that argument all that compelling. Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? I suspect the author and most other programmers might have some disagreements with their new monadic overlords. The point is that "colour" is introduced to make a meaningful distinction in order to achieve a desirable property. He's enamored by Go which erases this distinction, but it does so by giving up nearly all of the benefits of the event-driven model: very small captured state for resuming the continuation.
- lmm 7y ago
  > Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? The argument is the reverse: it's too hard to explicitly manage side effects, so we should make our functions implicitly, pervasively side-effecting. E.g. allowing any function to throw an exception without declaring this in their signature is widely agreed to be a better approach than Java-style checked exceptions; the argument goes that we should also allow any function to be async without declaring this in its signature. (I think there's some merit to the argument in languages that aren't powerful enough to express functions that are polymorphic over async-ness. Personally I use languages with higher-kinded types and then you get the best of both worlds: you have an explicit distinction between async and not, but you can write functions that work with both)
faitswulff 7y ago
I heard that Zig sidesteps this, but I'm not aware of the details.
hobofan 7y ago
I very much disagree that it does. The core pitfalls are pretty specific to JS, and don't exist in Rust. In Rust you can easily call an "async colored" function from a "sync colored" one by running it to completion with the executor of your choice. With that you can prevent async bleeding all over your codebase.

steveklabnik 7y ago

Yes. Engineering is all about tradeoffs. This is a downside, but it is made up for by all the upsides.

naasking 7y ago

Can't say I find that argument all that compelling. Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? I suspect the author and most other programmers might have some disagreements with their new monadic overlords. The point is that "colour" is introduced to make a meaningful distinction in order to achieve a desirable property. He's enamored by Go which erases this distinction, but it does so by giving up nearly all of the benefits of the event-driven model: very small captured state for resuming the continuation.

lmm 7y ago
> Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? The argument is the reverse: it's too hard to explicitly manage side effects, so we should make our functions implicitly, pervasively side-effecting. E.g. allowing any function to throw an exception without declaring this in their signature is widely agreed to be a better approach than Java-style checked exceptions; the argument goes that we should also allow any function to be async without declaring this in its signature. (I think there's some merit to the argument in languages that aren't powerful enough to express functions that are polymorphic over async-ness. Personally I use languages with higher-kinded types and then you get the best of both worlds: you have an explicit distinction between async and not, but you can write functions that work with both)

faitswulff 7y ago

I heard that Zig sidesteps this, but I'm not aware of the details.

hobofan 7y ago

I very much disagree that it does. The core pitfalls are pretty specific to JS, and don't exist in Rust. In Rust you can easily call an "async colored" function from a "sync colored" one by running it to completion with the executor of your choice. With that you can prevent async bleeding all over your codebase.