Proposal: `await.all {...}` for parallelism

Tom Boutell tom at
Fri Nov 22 13:44:16 UTC 2019

I am very sympathetic to pitches to allow more common cases for promise
libraries to be written in an "awaitful" syntax without thinking explicitly
about promises.

Howeever I think that changing the meaning of the semicolon in a particular
context has too much potential for confusion. As others have said, parallel
execution is different, and it should look and feel different. The most
basic assumption a developer makes (consecutive lines of code run
consecutively) is difficult to get away from; that's why we introduced
"await" in the first place, to bring back the ability to write
deterministic code with consecutive statements. Which sounds like a
reasonable ask, when it's put that way. (:

I did propose this recently:

for (const item of items concurrency 5) {
  await  doTheThing(item);

However in this case I'm not talking about consecutive statements, I'm only
talking about rules for simultaneously (in the sense of async, not threads)
running more than one instance of the block. So I'm not proposing that we
change the meaning of the semicolon(s) *within* the block in a way that
could mean that if you're looking at half the code in the middle you would
be likely to fundamentally misunderstand its operation.

I think that risk - that you can't tell what a semicolon means without
reference to the outer context - is what makes your proposal a bridge too
far for me.


APOSTROPHECMS | | he/him/his
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list