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

Jacob Bloom mr.jacob.bloom at
Thu Nov 21 23:42:13 UTC 2019

>>This [current] structure is also just fundamentally different from working
>>serially in async/await and it forces you to reason about the problem in a
>>specific way. This doesn't appear to be a conscious decision to force good
>>code practices
>Actually I'd argue that it is. Doing stuff concurrently is fundamentally
>different from doing it serially, and should be reasoned about every time you
>use it.

I agree that parallelism is different and should be handled with care,
but I don't think it follows that the best way to reason about
parallelism is the way that `Promise.all` encourages. Making something
more complicated doesn't necessarily mean you'll do a better job of
reasoning about it.

If you think the proposed syntax encourages poorly-reasoned-about
code, I'm open to iterating on it to find a syntax that works with the
developer to handle parallelism in a safe way, and also doesn't
require them to write too much boilerplate code.

On Thu, Nov 21, 2019 at 3:16 PM Naveen Chawla <naveen.chwl at> wrote:
> Yes of course, I was responding to your proposal and the subsequent email about it being incompatible with existing JavaScript because "await" on its own accepts non-promises, so wouldn't return an array of results from an array of promises, hence why I proposed await.all etc.
> On Thu, 21 Nov 2019 at 18:29, manuelbarzi <manuelbarzi at> wrote:
>>> I have a solution for that:
>>> const promises = [...]
>>> await.all promises //returns an array of results
>>> await.race promises //returns a single result
>> well, my proposal is exactly that, but doing `await.all` by default with just `await`.

More information about the es-discuss mailing list