4 ms·
The painful aspect of async over the other "colors" is that they require the programmer to manually re-annotate all "recolored" functions. E.g. let f call g wh
by snicker7 6y ago
The painful aspect of async over the other "colors" is that they require the programmer to manually re-annotate all "recolored" functions.
E.g. let f call g which calls h. And suppose you replace h with an async function. Then you'd have to manually annotate g and f as async functions too. You don't have to annotate a function as being allocating or not, so the allocation "color" isn't nearly as bad. Languages like Go or Julia or Zig that have "colorless" coroutines are much more robust.
- littlestymaar 6y agolet f call g which calls h. And suppose you replace h with an allocating function, then in Zig you have to manually add a allocator as a parameter in g and f and update their call site accordingly, because now they are also allocating. And suppose you replace h with a function that returns an error, then in Go you have to manually add an error as a return value in g and f. h become impure? Then g and f are not pure anymore either. h becomes Windows specific, then g and f are Windows specific[1]. The situation is highly similar. [1]: or you need to write a non-windows version of the work done by the h function, which fundamentally equivalent to calling block_on on an async function to make it a blocking one.
- deleted 6y ago[deleted]