Does async/await solve a real problem?
Tom Van Cutsem
tomvc.be at gmail.com
Thu Sep 11 23:00:24 PDT 2014
2014-09-11 16:22 GMT+02:00 Florian Bösch <pyalot at gmail.com>:
> A -> B -> C -> D -> E changes to
> A -> B -> C -> D -> async E and causes
> A await -> B await -> C await -> D await -> async E
> And of course if A, B, C or D is used anywhere else it percolates trough
> the entire call graph.
> Trying to protect people from interlaved code execution effects is noble.
> But doing so by introducing a rote thing to type everytime you change the
> code somewhere underneath is wrong. It's wrong because it breaks logic
> isolation, it becomes impossible to change part of the library/utiity code
> without this change affecting all code that uses it. This guarantees that
> it doesn't happen in practice, because it's too painful to do. It requires
> the code, that uses other code, to know about the internal behavior of that
Arguably, the fact that a function may suspend in mid-flight should be part
of its documentation (i.e. function signature), as it directly affects the
As an analogy, consider `IO` in Haskell: if you have this large piece of
purely functional code, and deep down you're all of a sudden introducing
mutable state, you will need to refactor the larger piece of code to reveal
that it in fact performs IO as well.
While this refactoring may be tedious (no disagreement there), it forces
you to review all affected code, which is good, because the dependencies of
that code may have changed (i.e. side-effect the client previously thought
would execute atomically may now no longer be atomic).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss