> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
