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

Naveen Chawla naveen.chwl at gmail.com
Thu Nov 21 23:58:11 UTC 2019


I do find the pattern of promise "all" combined with destructuring the
easiest way to handle parallelism. I think it's the only "deterministic"
parallel pattern code wise.

I think non determinism in code increases the probability of bugs.

On Thu, 21 Nov 2019, 23:42 Jacob Bloom, <mr.jacob.bloom at gmail.com> wrote:

> >>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 gmail.com>
> 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 gmail.com> 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`.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20191121/db1c257d/attachment.html>


More information about the es-discuss mailing list