In my mind there is a cognitive load cost in adding language constructs
(unless they significantly otherwise reduce cognitive load). In this case,
I find omitting the "await" would suffice for a lot of people, and for
those who want the loop to conceptually "hang" until all are completed
(which I find strange in of itself), I think synchronously collecting the
operations then doing a Promise.all is more understandable to a reader. Can
you imagine explaining a for loop that doesn't behave linearly, e.g.
imagine you have a variable outside the loop that is being modified on each
iteration - the whole thing would go haywire. Especially compared to
building an array followed by a Promise.all.
In my mind, the whole point of "await async" is to linearize asynchronous
programming, so that logical flow that happens to be asynchronous is
trivial to reason about, and read. In my mind the "concurrent" proposal
jeopardises that.
On Fri, 6 Sep 2019 at 22:05, Tom Boutell <t...@apostrophecms.com> wrote:
> > Can someone tell me exactly how just omitting "await" doesn't broadly
> achieve the "concurrency" objective?
>
> Omitting "await" gives us no assurance that all of the iterations
> completed prior to exit from the "for...of" loop.
>
> My proposal should have specified that regardless of whether "concurrency
> N" or "concurrent" is used, the loop will not exit until all of the items
> have successfully executed the loop body.
>
> > It could be probably added as a Promise.all(iterable, concurrency?)
>
> While this would be a useful extension to Promise.all and might be part of
> the underlying implementation of the language feature, this does not meet
> the goal of avoiding the cognitive load of shifting gears from the
> "async/await" pattern to thinking overtly about promises. There are similar
> implementations, such as the one in Bluebird, but the goal of the language
> feature is to expand the set of problems that can be solved without the
> cognitive load of collecting async function return values and then awaiting
> a library function that operates on them.
>
> My own belief is that the percentage of "await-friendly" use cases for
> asynchronous programming that come up for most developers is pretty close
> to 90%, and that a syntax for specifying concurrency would take it the rest
> of the way there, and be much appreciated by the developer who has written
> the "for...of { await ... }" loop and now wants to improve the performance
> in a simple way that is also likely to be safe (bounded concurrency).
>
> --
> Chief Software Architect
> Apostrophe Technologies
> Pronouns: he / him / his
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
