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

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
To simplify the problem of working with promises in parallel, I
propose this new syntax:

```javascript
async function initialize() {
  let foo, bar, baz;
  await.all {
    foo = (await request('foo.json')).data;
    bar = (await request('bar.json')).data;
    baz = (await request('baz.json')).data;
  }
  render(foo, bar, baz);
}
```

Each child statement of the curly braces is evaluated in parallel and
execution resumes when they've all resolved.

**The Problem:** with current syntax, the above function would
probably look something like this:

```javascript
async function initialize() {
  const [
    { data: foo }, // renaming response.data => foo
    { data: bar },
    { data: baz },
  ] = await Promise.all([
    request('foo.json'),
    request('bar.json'),
    request('baz.json'),
  ]);
  render(foo, bar, baz);
}
```

For this kind of use case, `Promise.all` leads to "parallel lists" of
promises and their return values, which must be kept in sync. Using
those values either requires (sometimes deep) destructuring or
temporary variables.

This 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, it's just a limitation that falls naturally
out of the current syntax. Thus, we have an opportunity to shift some
of the burden back to the language with this new syntax.

Here's the full proposal:
https://github.com/mrjacobbloom/proposal-await-all -- let me know what
you think!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jordan Harband
If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?

On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <[hidden email]> wrote:
To simplify the problem of working with promises in parallel, I
propose this new syntax:

```javascript
async function initialize() {
  let foo, bar, baz;
  await.all {
    foo = (await request('foo.json')).data;
    bar = (await request('bar.json')).data;
    baz = (await request('baz.json')).data;
  }
  render(foo, bar, baz);
}
```

Each child statement of the curly braces is evaluated in parallel and
execution resumes when they've all resolved.

**The Problem:** with current syntax, the above function would
probably look something like this:

```javascript
async function initialize() {
  const [
    { data: foo }, // renaming response.data => foo
    { data: bar },
    { data: baz },
  ] = await Promise.all([
    request('foo.json'),
    request('bar.json'),
    request('baz.json'),
  ]);
  render(foo, bar, baz);
}
```

For this kind of use case, `Promise.all` leads to "parallel lists" of
promises and their return values, which must be kept in sync. Using
those values either requires (sometimes deep) destructuring or
temporary variables.

This 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, it's just a limitation that falls naturally
out of the current syntax. Thus, we have an opportunity to shift some
of the burden back to the language with this new syntax.

Here's the full proposal:
https://github.com/mrjacobbloom/proposal-await-all -- let me know what
you think!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Guy Bedford-2
Typically I find I want to loop over an iterator of items and apply a function body of work on them in parallel.

So it would be nice to support full blocks of statements that can do this work in parallel, instead of relying on just expressions or functions to achieve this.

Extending for loops to have a parallel form is another option (I seem to recall something similar brought up before here):

```
for await.all (const entry of entries) {
  await doWork(entry);
}
```

Whether async iteration should be supported or treated as sync or parallel is another question though, and possibly a confusion of the form.

On Tue, 19 Nov 2019 at 23:20, Jordan Harband <[hidden email]> wrote:
If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?

On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <[hidden email]> wrote:
To simplify the problem of working with promises in parallel, I
propose this new syntax:

```javascript
async function initialize() {
  let foo, bar, baz;
  await.all {
    foo = (await request('foo.json')).data;
    bar = (await request('bar.json')).data;
    baz = (await request('baz.json')).data;
  }
  render(foo, bar, baz);
}
```

Each child statement of the curly braces is evaluated in parallel and
execution resumes when they've all resolved.

**The Problem:** with current syntax, the above function would
probably look something like this:

```javascript
async function initialize() {
  const [
    { data: foo }, // renaming response.data => foo
    { data: bar },
    { data: baz },
  ] = await Promise.all([
    request('foo.json'),
    request('bar.json'),
    request('baz.json'),
  ]);
  render(foo, bar, baz);
}
```

For this kind of use case, `Promise.all` leads to "parallel lists" of
promises and their return values, which must be kept in sync. Using
those values either requires (sometimes deep) destructuring or
temporary variables.

This 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, it's just a limitation that falls naturally
out of the current syntax. Thus, we have an opportunity to shift some
of the burden back to the language with this new syntax.

Here's the full proposal:
https://github.com/mrjacobbloom/proposal-await-all -- let me know what
you think!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
In reply to this post by Jordan Harband
Regarding the other `Promise` methods, this syntax could certainly
extend to all of them (that's part of the reason I chose this syntax,
to leave that option open).

`await.any` and `await.race` would work analogously to `await.all`,
but since we're no longer dealing with return values there's no good
way to get the value that won the race. This is fine as long as you're
not dependent on that value and only care about executing some code as
soon as the race is won. The best way I can think of to get the
winning value is something like this:

```javascript
async function myFunc() {
  let value1, value2;
  await.any {
    value1 = await foo;
    value2 = await bar;
  }
  const firstResult = value1 || value2; // could also use ??
}
```

...which isn't any easier than using `Promise.any`.

`await.allSettled` would, in many cases, be the same as `Promise.all`
except it would also swallow errors. I'd have to think more about its
use cases but it could be implemented the same way.

On Tue, Nov 19, 2019 at 9:20 PM Jordan Harband <[hidden email]> wrote:

>
> If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?
>
> On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <[hidden email]> wrote:
>>
>> To simplify the problem of working with promises in parallel, I
>> propose this new syntax:
>>
>> ```javascript
>> async function initialize() {
>>   let foo, bar, baz;
>>   await.all {
>>     foo = (await request('foo.json')).data;
>>     bar = (await request('bar.json')).data;
>>     baz = (await request('baz.json')).data;
>>   }
>>   render(foo, bar, baz);
>> }
>> ```
>>
>> Each child statement of the curly braces is evaluated in parallel and
>> execution resumes when they've all resolved.
>>
>> **The Problem:** with current syntax, the above function would
>> probably look something like this:
>>
>> ```javascript
>> async function initialize() {
>>   const [
>>     { data: foo }, // renaming response.data => foo
>>     { data: bar },
>>     { data: baz },
>>   ] = await Promise.all([
>>     request('foo.json'),
>>     request('bar.json'),
>>     request('baz.json'),
>>   ]);
>>   render(foo, bar, baz);
>> }
>> ```
>>
>> For this kind of use case, `Promise.all` leads to "parallel lists" of
>> promises and their return values, which must be kept in sync. Using
>> those values either requires (sometimes deep) destructuring or
>> temporary variables.
>>
>> This 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, it's just a limitation that falls naturally
>> out of the current syntax. Thus, we have an opportunity to shift some
>> of the burden back to the language with this new syntax.
>>
>> Here's the full proposal:
>> https://github.com/mrjacobbloom/proposal-await-all -- let me know what
>> you think!
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
In reply to this post by Guy Bedford-2
Regarding parallel for-loops: I'd consider that a separate problem.
You'd want parallel for-loops for things like requests to the same
API, where each promise is handled the same way. `await.all` is more
for handling disparate tasks in parallel without having to resort to
thinking in terms of arrays and iteration.

On Tue, Nov 19, 2019 at 10:27 PM Guy Bedford <[hidden email]> wrote:

>
> Typically I find I want to loop over an iterator of items and apply a function body of work on them in parallel.
>
> So it would be nice to support full blocks of statements that can do this work in parallel, instead of relying on just expressions or functions to achieve this.
>
> Extending for loops to have a parallel form is another option (I seem to recall something similar brought up before here):
>
> ```
> for await.all (const entry of entries) {
>   await doWork(entry);
> }
> ```
>
> Whether async iteration should be supported or treated as sync or parallel is another question though, and possibly a confusion of the form.
>
> On Tue, 19 Nov 2019 at 23:20, Jordan Harband <[hidden email]> wrote:
>>
>> If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?
>>
>> On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <[hidden email]> wrote:
>>>
>>> To simplify the problem of working with promises in parallel, I
>>> propose this new syntax:
>>>
>>> ```javascript
>>> async function initialize() {
>>>   let foo, bar, baz;
>>>   await.all {
>>>     foo = (await request('foo.json')).data;
>>>     bar = (await request('bar.json')).data;
>>>     baz = (await request('baz.json')).data;
>>>   }
>>>   render(foo, bar, baz);
>>> }
>>> ```
>>>
>>> Each child statement of the curly braces is evaluated in parallel and
>>> execution resumes when they've all resolved.
>>>
>>> **The Problem:** with current syntax, the above function would
>>> probably look something like this:
>>>
>>> ```javascript
>>> async function initialize() {
>>>   const [
>>>     { data: foo }, // renaming response.data => foo
>>>     { data: bar },
>>>     { data: baz },
>>>   ] = await Promise.all([
>>>     request('foo.json'),
>>>     request('bar.json'),
>>>     request('baz.json'),
>>>   ]);
>>>   render(foo, bar, baz);
>>> }
>>> ```
>>>
>>> For this kind of use case, `Promise.all` leads to "parallel lists" of
>>> promises and their return values, which must be kept in sync. Using
>>> those values either requires (sometimes deep) destructuring or
>>> temporary variables.
>>>
>>> This 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, it's just a limitation that falls naturally
>>> out of the current syntax. Thus, we have an opportunity to shift some
>>> of the burden back to the language with this new syntax.
>>>
>>> Here's the full proposal:
>>> https://github.com/mrjacobbloom/proposal-await-all -- let me know what
>>> you think!
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Cyril Auburtin
There's `for await` loops since recently, there could be `await for` loops for wrapping the whole execution of a loop

```js
console.time(1);
await for (const fn of [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]) {
  console.timeLog(1, await fn());
}
console.timeEnd(1);
```

This would log the same than:

```js
console.time(1);
await Promise.all(
  [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]
    .map(async fn => { console.timeLog(1, await fn()) })
);
console.timeEnd(1);
/*
1: 51.066162109375ms a
1: 80.998291015625ms b
1: 81.315185546875ms
*/
```

without `await for`, things are serial:
```js
console.time(1);
for (const fn of [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]) {
  console.timeLog(1, await fn());
}
console.timeEnd(1);
/*
1: 50.68212890625ms a
1: 130.9951171875ms b
1: 131.1162109375ms
*/
```

(`var delay = t => new Promise(r => setTimeout(r, t));`)

On Wed, Nov 20, 2019 at 6:44 AM Jacob Bloom <[hidden email]> wrote:
Regarding parallel for-loops: I'd consider that a separate problem.
You'd want parallel for-loops for things like requests to the same
API, where each promise is handled the same way. `await.all` is more
for handling disparate tasks in parallel without having to resort to
thinking in terms of arrays and iteration.

On Tue, Nov 19, 2019 at 10:27 PM Guy Bedford <[hidden email]> wrote:
>
> Typically I find I want to loop over an iterator of items and apply a function body of work on them in parallel.
>
> So it would be nice to support full blocks of statements that can do this work in parallel, instead of relying on just expressions or functions to achieve this.
>
> Extending for loops to have a parallel form is another option (I seem to recall something similar brought up before here):
>
> ```
> for await.all (const entry of entries) {
>   await doWork(entry);
> }
> ```
>
> Whether async iteration should be supported or treated as sync or parallel is another question though, and possibly a confusion of the form.
>
> On Tue, 19 Nov 2019 at 23:20, Jordan Harband <[hidden email]> wrote:
>>
>> If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?
>>
>> On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <[hidden email]> wrote:
>>>
>>> To simplify the problem of working with promises in parallel, I
>>> propose this new syntax:
>>>
>>> ```javascript
>>> async function initialize() {
>>>   let foo, bar, baz;
>>>   await.all {
>>>     foo = (await request('foo.json')).data;
>>>     bar = (await request('bar.json')).data;
>>>     baz = (await request('baz.json')).data;
>>>   }
>>>   render(foo, bar, baz);
>>> }
>>> ```
>>>
>>> Each child statement of the curly braces is evaluated in parallel and
>>> execution resumes when they've all resolved.
>>>
>>> **The Problem:** with current syntax, the above function would
>>> probably look something like this:
>>>
>>> ```javascript
>>> async function initialize() {
>>>   const [
>>>     { data: foo }, // renaming response.data => foo
>>>     { data: bar },
>>>     { data: baz },
>>>   ] = await Promise.all([
>>>     request('foo.json'),
>>>     request('bar.json'),
>>>     request('baz.json'),
>>>   ]);
>>>   render(foo, bar, baz);
>>> }
>>> ```
>>>
>>> For this kind of use case, `Promise.all` leads to "parallel lists" of
>>> promises and their return values, which must be kept in sync. Using
>>> those values either requires (sometimes deep) destructuring or
>>> temporary variables.
>>>
>>> This 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, it's just a limitation that falls naturally
>>> out of the current syntax. Thus, we have an opportunity to shift some
>>> of the burden back to the language with this new syntax.
>>>
>>> Here's the full proposal:
>>> https://github.com/mrjacobbloom/proposal-await-all -- let me know what
>>> you think!
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Naveen Chawla
I don't like the idea of await behaving differently inside vs outside of the "await.all" block, and I think is a source of bugs:

await.all {
    const x = await doSomethingAsync();
    //x is still undefined here! Not the case outside of an await.all block
}

Maybe if you drop the "await" in your example:

await.all {
    const x = doSomethingAsync();
    //x is just the promise here, but at least is the same whether inside or outside of the await.all block
}

...but that still waits for the async functions to complete, I think it would cause fewer bugs and would seem to still satisfy the motivation?

On Wed, 20 Nov 2019 at 09:06, Cyril Auburtin <[hidden email]> wrote:
There's `for await` loops since recently, there could be `await for` loops for wrapping the whole execution of a loop

```js
console.time(1);
await for (const fn of [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]) {
  console.timeLog(1, await fn());
}
console.timeEnd(1);
```

This would log the same than:

```js
console.time(1);
await Promise.all(
  [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]
    .map(async fn => { console.timeLog(1, await fn()) })
);
console.timeEnd(1);
/*
1: 51.066162109375ms a
1: 80.998291015625ms b
1: 81.315185546875ms
*/
```

without `await for`, things are serial:
```js
console.time(1);
for (const fn of [()=>delay(50).then(()=>'a'), ()=>delay(80).then(()=>'b')]) {
  console.timeLog(1, await fn());
}
console.timeEnd(1);
/*
1: 50.68212890625ms a
1: 130.9951171875ms b
1: 131.1162109375ms
*/
```

(`var delay = t => new Promise(r => setTimeout(r, t));`)

On Wed, Nov 20, 2019 at 6:44 AM Jacob Bloom <[hidden email]> wrote:
Regarding parallel for-loops: I'd consider that a separate problem.
You'd want parallel for-loops for things like requests to the same
API, where each promise is handled the same way. `await.all` is more
for handling disparate tasks in parallel without having to resort to
thinking in terms of arrays and iteration.

On Tue, Nov 19, 2019 at 10:27 PM Guy Bedford <[hidden email]> wrote:
>
> Typically I find I want to loop over an iterator of items and apply a function body of work on them in parallel.
>
> So it would be nice to support full blocks of statements that can do this work in parallel, instead of relying on just expressions or functions to achieve this.
>
> Extending for loops to have a parallel form is another option (I seem to recall something similar brought up before here):
>
> ```
> for await.all (const entry of entries) {
>   await doWork(entry);
> }
> ```
>
> Whether async iteration should be supported or treated as sync or parallel is another question though, and possibly a confusion of the form.
>
> On Tue, 19 Nov 2019 at 23:20, Jordan Harband <[hidden email]> wrote:
>>
>> If we have `await.all`, what about `await.race`, `await.allSettled`, `await.any`?
>>
>> On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom <[hidden email]> wrote:
>>>
>>> To simplify the problem of working with promises in parallel, I
>>> propose this new syntax:
>>>
>>> ```javascript
>>> async function initialize() {
>>>   let foo, bar, baz;
>>>   await.all {
>>>     foo = (await request('foo.json')).data;
>>>     bar = (await request('bar.json')).data;
>>>     baz = (await request('baz.json')).data;
>>>   }
>>>   render(foo, bar, baz);
>>> }
>>> ```
>>>
>>> Each child statement of the curly braces is evaluated in parallel and
>>> execution resumes when they've all resolved.
>>>
>>> **The Problem:** with current syntax, the above function would
>>> probably look something like this:
>>>
>>> ```javascript
>>> async function initialize() {
>>>   const [
>>>     { data: foo }, // renaming response.data => foo
>>>     { data: bar },
>>>     { data: baz },
>>>   ] = await Promise.all([
>>>     request('foo.json'),
>>>     request('bar.json'),
>>>     request('baz.json'),
>>>   ]);
>>>   render(foo, bar, baz);
>>> }
>>> ```
>>>
>>> For this kind of use case, `Promise.all` leads to "parallel lists" of
>>> promises and their return values, which must be kept in sync. Using
>>> those values either requires (sometimes deep) destructuring or
>>> temporary variables.
>>>
>>> This 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, it's just a limitation that falls naturally
>>> out of the current syntax. Thus, we have an opportunity to shift some
>>> of the burden back to the language with this new syntax.
>>>
>>> Here's the full proposal:
>>> https://github.com/mrjacobbloom/proposal-await-all -- let me know what
>>> you think!
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Bergi
In reply to this post by Jacob Bloom
Hello!

> 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.

kind regards,
 Bergi
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
>Maybe if you drop the "await" in your example:
>
>```javascript
>await.all {
>    const x = doSomethingAsync();
>    //x is just the promise here
>}
>```
>
>...but that still waits for the async functions to complete, I think it would
>cause fewer bugs and would seem to still satisfy the motivation?

It doesn't seem like the `await.all` block is doing anything in that
case. That code seems equivalent to this:

```javascript
const x = doSomethingAsync();
myFunction(await x)
```

>```javascript
>await.all {
>  const x = await doSomethingAsync();
>  //x is still undefined here!
>}
>```

You bring up a good point about scoping and race conditions. It's a
little tricky since the curly braces create a block scope but none of
the parallel statements should be allowed to access each-other's
variables, it's almost like each statement should have its own scope.
Maybe it'd be better to have a syntax that ensures a set of curly
braces for each parallel task? Async do-expressions could be a good
solution (assuming they'd work kind of like an async IIFE):

```javascript
async function initialize() {
  let foo, bar, baz;
  await Promise.all([
    async do { foo = (await request('foo.json')).data },
    async do { bar = (await request('bar.json')).data },
    async do { baz = (await request('baz.json')).data },
  ]);
  render(foo, bar, baz);
}
```

(this is also a less drastic syntax change that piggybacks on an
existing proposal)

On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:

>
> Hello!
>
> > 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.
>
> kind regards,
>  Bergi
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
...strike that, I misread the "but that still waits for the async
functions to complete" part. So what you're proposing is that
everything functions normally inside the curly braces, but execution
doesn't continue until all promises have resolved? So your example
would work essentially like this:

```javascript
const x = doSomethingAsync();
const y = doSomethingElseAsync();
await x, await y;
// all promises are resolved by now, but
// still need to use await to unbox the values
someFunction(await x, await y);
```

On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:

>
> >Maybe if you drop the "await" in your example:
> >
> >```javascript
> >await.all {
> >    const x = doSomethingAsync();
> >    //x is just the promise here
> >}
> >```
> >
> >...but that still waits for the async functions to complete, I think it would
> >cause fewer bugs and would seem to still satisfy the motivation?
>
> It doesn't seem like the `await.all` block is doing anything in that
> case. That code seems equivalent to this:
>
> ```javascript
> const x = doSomethingAsync();
> myFunction(await x)
> ```
>
> >```javascript
> >await.all {
> >  const x = await doSomethingAsync();
> >  //x is still undefined here!
> >}
> >```
>
> You bring up a good point about scoping and race conditions. It's a
> little tricky since the curly braces create a block scope but none of
> the parallel statements should be allowed to access each-other's
> variables, it's almost like each statement should have its own scope.
> Maybe it'd be better to have a syntax that ensures a set of curly
> braces for each parallel task? Async do-expressions could be a good
> solution (assuming they'd work kind of like an async IIFE):
>
> ```javascript
> async function initialize() {
>   let foo, bar, baz;
>   await Promise.all([
>     async do { foo = (await request('foo.json')).data },
>     async do { bar = (await request('bar.json')).data },
>     async do { baz = (await request('baz.json')).data },
>   ]);
>   render(foo, bar, baz);
> }
> ```
>
> (this is also a less drastic syntax change that piggybacks on an
> existing proposal)
>
> On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> >
> > Hello!
> >
> > > 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.
> >
> > kind regards,
> >  Bergi
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-3
Just FYI, I previously suggested a couple things substantially more
flexible than this [1] [2] (originated from this [3]), and it mostly
fell flat due to being highly premature. Anything exclusive to
promises is unlikely to win as library methods exist for basically all
use cases and from my experience, committee members are in general
very hesitant to add syntax for anything that doesn't pay for itself
well. Similar questions have come up a few times in the past, too, and
I've commented on two of them. [4] [5]

If anything, I don't feel we know the problem space well enough, and
the language lacks the primitives needed to really dig into it. (This
is why I came up with my generator forking strawman. [6])

[1]: https://github.com/isiahmeadows/non-linear-proposal
[2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
[3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
[4]: https://esdiscuss.org/topic/stream-async-await
[5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
[6]: https://github.com/isiahmeadows/proposal-generator-fork

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:

>
> ...strike that, I misread the "but that still waits for the async
> functions to complete" part. So what you're proposing is that
> everything functions normally inside the curly braces, but execution
> doesn't continue until all promises have resolved? So your example
> would work essentially like this:
>
> ```javascript
> const x = doSomethingAsync();
> const y = doSomethingElseAsync();
> await x, await y;
> // all promises are resolved by now, but
> // still need to use await to unbox the values
> someFunction(await x, await y);
> ```
>
> On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
> >
> > >Maybe if you drop the "await" in your example:
> > >
> > >```javascript
> > >await.all {
> > >    const x = doSomethingAsync();
> > >    //x is just the promise here
> > >}
> > >```
> > >
> > >...but that still waits for the async functions to complete, I think it would
> > >cause fewer bugs and would seem to still satisfy the motivation?
> >
> > It doesn't seem like the `await.all` block is doing anything in that
> > case. That code seems equivalent to this:
> >
> > ```javascript
> > const x = doSomethingAsync();
> > myFunction(await x)
> > ```
> >
> > >```javascript
> > >await.all {
> > >  const x = await doSomethingAsync();
> > >  //x is still undefined here!
> > >}
> > >```
> >
> > You bring up a good point about scoping and race conditions. It's a
> > little tricky since the curly braces create a block scope but none of
> > the parallel statements should be allowed to access each-other's
> > variables, it's almost like each statement should have its own scope.
> > Maybe it'd be better to have a syntax that ensures a set of curly
> > braces for each parallel task? Async do-expressions could be a good
> > solution (assuming they'd work kind of like an async IIFE):
> >
> > ```javascript
> > async function initialize() {
> >   let foo, bar, baz;
> >   await Promise.all([
> >     async do { foo = (await request('foo.json')).data },
> >     async do { bar = (await request('bar.json')).data },
> >     async do { baz = (await request('baz.json')).data },
> >   ]);
> >   render(foo, bar, baz);
> > }
> > ```
> >
> > (this is also a less drastic syntax change that piggybacks on an
> > existing proposal)
> >
> > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> > >
> > > Hello!
> > >
> > > > 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.
> > >
> > > kind regards,
> > >  Bergi
> > > _______________________________________________
> > > es-discuss mailing list
> > > [hidden email]
> > > https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

manuelbarzi
why not just `await` as already is, but supporting an iterable / array of promises, as `Promise.all` already does, automatically discerning single promises vs multiple ones:

```
const promises = [...]

// in parallel (`await` automatically acts as `Promise.all` here)
const results = await promises

results.forEach(result => ...)
```



On Thu, Nov 21, 2019 at 3:37 AM Isiah Meadows <[hidden email]> wrote:
Just FYI, I previously suggested a couple things substantially more
flexible than this [1] [2] (originated from this [3]), and it mostly
fell flat due to being highly premature. Anything exclusive to
promises is unlikely to win as library methods exist for basically all
use cases and from my experience, committee members are in general
very hesitant to add syntax for anything that doesn't pay for itself
well. Similar questions have come up a few times in the past, too, and
I've commented on two of them. [4] [5]

If anything, I don't feel we know the problem space well enough, and
the language lacks the primitives needed to really dig into it. (This
is why I came up with my generator forking strawman. [6])

[1]: https://github.com/isiahmeadows/non-linear-proposal
[2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
[3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
[4]: https://esdiscuss.org/topic/stream-async-await
[5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
[6]: https://github.com/isiahmeadows/proposal-generator-fork

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:
>
> ...strike that, I misread the "but that still waits for the async
> functions to complete" part. So what you're proposing is that
> everything functions normally inside the curly braces, but execution
> doesn't continue until all promises have resolved? So your example
> would work essentially like this:
>
> ```javascript
> const x = doSomethingAsync();
> const y = doSomethingElseAsync();
> await x, await y;
> // all promises are resolved by now, but
> // still need to use await to unbox the values
> someFunction(await x, await y);
> ```
>
> On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
> >
> > >Maybe if you drop the "await" in your example:
> > >
> > >```javascript
> > >await.all {
> > >    const x = doSomethingAsync();
> > >    //x is just the promise here
> > >}
> > >```
> > >
> > >...but that still waits for the async functions to complete, I think it would
> > >cause fewer bugs and would seem to still satisfy the motivation?
> >
> > It doesn't seem like the `await.all` block is doing anything in that
> > case. That code seems equivalent to this:
> >
> > ```javascript
> > const x = doSomethingAsync();
> > myFunction(await x)
> > ```
> >
> > >```javascript
> > >await.all {
> > >  const x = await doSomethingAsync();
> > >  //x is still undefined here!
> > >}
> > >```
> >
> > You bring up a good point about scoping and race conditions. It's a
> > little tricky since the curly braces create a block scope but none of
> > the parallel statements should be allowed to access each-other's
> > variables, it's almost like each statement should have its own scope.
> > Maybe it'd be better to have a syntax that ensures a set of curly
> > braces for each parallel task? Async do-expressions could be a good
> > solution (assuming they'd work kind of like an async IIFE):
> >
> > ```javascript
> > async function initialize() {
> >   let foo, bar, baz;
> >   await Promise.all([
> >     async do { foo = (await request('foo.json')).data },
> >     async do { bar = (await request('bar.json')).data },
> >     async do { baz = (await request('baz.json')).data },
> >   ]);
> >   render(foo, bar, baz);
> > }
> > ```
> >
> > (this is also a less drastic syntax change that piggybacks on an
> > existing proposal)
> >
> > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> > >
> > > Hello!
> > >
> > > > 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.
> > >
> > > kind regards,
> > >  Bergi
> > > _______________________________________________
> > > es-discuss mailing list
> > > [hidden email]
> > > https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
In reply to this post by Isiah Meadows-3
>Just FYI, I previously suggested a couple things substantially more
>flexible than this

Ah, thank you for bringing those proposals to my attention. I looked
through the archives for relevant discussions but I must've missed
them.

It seems like we converged on a similar syntax for what you called
"merging," and the idea that there ought to be a separate syntax for
iteration. I don't know whether that means that this is the right
solution or just the most obvious one, but either way it's encouraging
to know that other people have the same difficulties with the current
syntax and are thinking about the problem.

>from my experience, committee members are in general
>very hesitant to add syntax for anything that doesn't pay for
>itself well

Yeah, I figured the bar would be high for new syntax. I've run into
the awkwardness of dealing with distinct parallel tasks several times,
and a few of the people I discussed it with were in the same boat, so
I wrote up this proposal thinking it might have a wide appeal. The
proposed syntax desugars via a relatively simple transformation but
encourages developers to reason about the problem in a completely
different way that I'd argue is more intuitive. Whether the committee
agrees and thinks it justifies a new syntax remains to be seen, but
either way I'm excited to see where this discussion goes (whether it
leads to the proposed syntax, to some other syntax, or to somewhere
else entirely).

As a side note: thank you to everyone for the thoughtful questions and
responses, I had no idea what to expect from this thread and it's gone
better than I could've hoped for. Thank you for not immediately
shooting down a proposal that looks similar to other proposals before
it.

On Wed, Nov 20, 2019 at 7:36 PM Isiah Meadows <[hidden email]> wrote:

>
> Just FYI, I previously suggested a couple things substantially more
> flexible than this [1] [2] (originated from this [3]), and it mostly
> fell flat due to being highly premature. Anything exclusive to
> promises is unlikely to win as library methods exist for basically all
> use cases and from my experience, committee members are in general
> very hesitant to add syntax for anything that doesn't pay for itself
> well. Similar questions have come up a few times in the past, too, and
> I've commented on two of them. [4] [5]
>
> If anything, I don't feel we know the problem space well enough, and
> the language lacks the primitives needed to really dig into it. (This
> is why I came up with my generator forking strawman. [6])
>
> [1]: https://github.com/isiahmeadows/non-linear-proposal
> [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
> [3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
> [4]: https://esdiscuss.org/topic/stream-async-await
> [5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
> [6]: https://github.com/isiahmeadows/proposal-generator-fork
>
> -----
>
> Isiah Meadows
> [hidden email]
> www.isiahmeadows.com
>
> On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:
> >
> > ...strike that, I misread the "but that still waits for the async
> > functions to complete" part. So what you're proposing is that
> > everything functions normally inside the curly braces, but execution
> > doesn't continue until all promises have resolved? So your example
> > would work essentially like this:
> >
> > ```javascript
> > const x = doSomethingAsync();
> > const y = doSomethingElseAsync();
> > await x, await y;
> > // all promises are resolved by now, but
> > // still need to use await to unbox the values
> > someFunction(await x, await y);
> > ```
> >
> > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
> > >
> > > >Maybe if you drop the "await" in your example:
> > > >
> > > >```javascript
> > > >await.all {
> > > >    const x = doSomethingAsync();
> > > >    //x is just the promise here
> > > >}
> > > >```
> > > >
> > > >...but that still waits for the async functions to complete, I think it would
> > > >cause fewer bugs and would seem to still satisfy the motivation?
> > >
> > > It doesn't seem like the `await.all` block is doing anything in that
> > > case. That code seems equivalent to this:
> > >
> > > ```javascript
> > > const x = doSomethingAsync();
> > > myFunction(await x)
> > > ```
> > >
> > > >```javascript
> > > >await.all {
> > > >  const x = await doSomethingAsync();
> > > >  //x is still undefined here!
> > > >}
> > > >```
> > >
> > > You bring up a good point about scoping and race conditions. It's a
> > > little tricky since the curly braces create a block scope but none of
> > > the parallel statements should be allowed to access each-other's
> > > variables, it's almost like each statement should have its own scope.
> > > Maybe it'd be better to have a syntax that ensures a set of curly
> > > braces for each parallel task? Async do-expressions could be a good
> > > solution (assuming they'd work kind of like an async IIFE):
> > >
> > > ```javascript
> > > async function initialize() {
> > >   let foo, bar, baz;
> > >   await Promise.all([
> > >     async do { foo = (await request('foo.json')).data },
> > >     async do { bar = (await request('bar.json')).data },
> > >     async do { baz = (await request('baz.json')).data },
> > >   ]);
> > >   render(foo, bar, baz);
> > > }
> > > ```
> > >
> > > (this is also a less drastic syntax change that piggybacks on an
> > > existing proposal)
> > >
> > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> > > >
> > > > Hello!
> > > >
> > > > > 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.
> > > >
> > > > kind regards,
> > > >  Bergi
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > [hidden email]
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
>why not just `await` as already is, but supporting an
>iterable / array of promises, as `Promise.all` already does

`await` can already accept a non-promise, so I believe that'd be
breaking syntax if `Array.prototype.then` is set. It also requires
collecting the promises in an array, which is what the proposed syntax
is trying to avoid.

On Thu, Nov 21, 2019 at 2:41 AM Jacob Bloom <[hidden email]> wrote:

>
> >Just FYI, I previously suggested a couple things substantially more
> >flexible than this
>
> Ah, thank you for bringing those proposals to my attention. I looked
> through the archives for relevant discussions but I must've missed
> them.
>
> It seems like we converged on a similar syntax for what you called
> "merging," and the idea that there ought to be a separate syntax for
> iteration. I don't know whether that means that this is the right
> solution or just the most obvious one, but either way it's encouraging
> to know that other people have the same difficulties with the current
> syntax and are thinking about the problem.
>
> >from my experience, committee members are in general
> >very hesitant to add syntax for anything that doesn't pay for
> >itself well
>
> Yeah, I figured the bar would be high for new syntax. I've run into
> the awkwardness of dealing with distinct parallel tasks several times,
> and a few of the people I discussed it with were in the same boat, so
> I wrote up this proposal thinking it might have a wide appeal. The
> proposed syntax desugars via a relatively simple transformation but
> encourages developers to reason about the problem in a completely
> different way that I'd argue is more intuitive. Whether the committee
> agrees and thinks it justifies a new syntax remains to be seen, but
> either way I'm excited to see where this discussion goes (whether it
> leads to the proposed syntax, to some other syntax, or to somewhere
> else entirely).
>
> As a side note: thank you to everyone for the thoughtful questions and
> responses, I had no idea what to expect from this thread and it's gone
> better than I could've hoped for. Thank you for not immediately
> shooting down a proposal that looks similar to other proposals before
> it.
>
> On Wed, Nov 20, 2019 at 7:36 PM Isiah Meadows <[hidden email]> wrote:
> >
> > Just FYI, I previously suggested a couple things substantially more
> > flexible than this [1] [2] (originated from this [3]), and it mostly
> > fell flat due to being highly premature. Anything exclusive to
> > promises is unlikely to win as library methods exist for basically all
> > use cases and from my experience, committee members are in general
> > very hesitant to add syntax for anything that doesn't pay for itself
> > well. Similar questions have come up a few times in the past, too, and
> > I've commented on two of them. [4] [5]
> >
> > If anything, I don't feel we know the problem space well enough, and
> > the language lacks the primitives needed to really dig into it. (This
> > is why I came up with my generator forking strawman. [6])
> >
> > [1]: https://github.com/isiahmeadows/non-linear-proposal
> > [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
> > [3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
> > [4]: https://esdiscuss.org/topic/stream-async-await
> > [5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
> > [6]: https://github.com/isiahmeadows/proposal-generator-fork
> >
> > -----
> >
> > Isiah Meadows
> > [hidden email]
> > www.isiahmeadows.com
> >
> > On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:
> > >
> > > ...strike that, I misread the "but that still waits for the async
> > > functions to complete" part. So what you're proposing is that
> > > everything functions normally inside the curly braces, but execution
> > > doesn't continue until all promises have resolved? So your example
> > > would work essentially like this:
> > >
> > > ```javascript
> > > const x = doSomethingAsync();
> > > const y = doSomethingElseAsync();
> > > await x, await y;
> > > // all promises are resolved by now, but
> > > // still need to use await to unbox the values
> > > someFunction(await x, await y);
> > > ```
> > >
> > > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
> > > >
> > > > >Maybe if you drop the "await" in your example:
> > > > >
> > > > >```javascript
> > > > >await.all {
> > > > >    const x = doSomethingAsync();
> > > > >    //x is just the promise here
> > > > >}
> > > > >```
> > > > >
> > > > >...but that still waits for the async functions to complete, I think it would
> > > > >cause fewer bugs and would seem to still satisfy the motivation?
> > > >
> > > > It doesn't seem like the `await.all` block is doing anything in that
> > > > case. That code seems equivalent to this:
> > > >
> > > > ```javascript
> > > > const x = doSomethingAsync();
> > > > myFunction(await x)
> > > > ```
> > > >
> > > > >```javascript
> > > > >await.all {
> > > > >  const x = await doSomethingAsync();
> > > > >  //x is still undefined here!
> > > > >}
> > > > >```
> > > >
> > > > You bring up a good point about scoping and race conditions. It's a
> > > > little tricky since the curly braces create a block scope but none of
> > > > the parallel statements should be allowed to access each-other's
> > > > variables, it's almost like each statement should have its own scope.
> > > > Maybe it'd be better to have a syntax that ensures a set of curly
> > > > braces for each parallel task? Async do-expressions could be a good
> > > > solution (assuming they'd work kind of like an async IIFE):
> > > >
> > > > ```javascript
> > > > async function initialize() {
> > > >   let foo, bar, baz;
> > > >   await Promise.all([
> > > >     async do { foo = (await request('foo.json')).data },
> > > >     async do { bar = (await request('bar.json')).data },
> > > >     async do { baz = (await request('baz.json')).data },
> > > >   ]);
> > > >   render(foo, bar, baz);
> > > > }
> > > > ```
> > > >
> > > > (this is also a less drastic syntax change that piggybacks on an
> > > > existing proposal)
> > > >
> > > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > > 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.
> > > > >
> > > > > kind regards,
> > > > >  Bergi
> > > > > _______________________________________________
> > > > > es-discuss mailing list
> > > > > [hidden email]
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > _______________________________________________
> > > es-discuss mailing list
> > > [hidden email]
> > > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

manuelbarzi
AFAIK `await` can only accept an `expression` as a `Promise`, not other thing: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await

On Thu, Nov 21, 2019 at 10:46 AM Jacob Bloom <[hidden email]> wrote:
>why not just `await` as already is, but supporting an
>iterable / array of promises, as `Promise.all` already does

`await` can already accept a non-promise, so I believe that'd be
breaking syntax if `Array.prototype.then` is set. It also requires
collecting the promises in an array, which is what the proposed syntax
is trying to avoid.

On Thu, Nov 21, 2019 at 2:41 AM Jacob Bloom <[hidden email]> wrote:
>
> >Just FYI, I previously suggested a couple things substantially more
> >flexible than this
>
> Ah, thank you for bringing those proposals to my attention. I looked
> through the archives for relevant discussions but I must've missed
> them.
>
> It seems like we converged on a similar syntax for what you called
> "merging," and the idea that there ought to be a separate syntax for
> iteration. I don't know whether that means that this is the right
> solution or just the most obvious one, but either way it's encouraging
> to know that other people have the same difficulties with the current
> syntax and are thinking about the problem.
>
> >from my experience, committee members are in general
> >very hesitant to add syntax for anything that doesn't pay for
> >itself well
>
> Yeah, I figured the bar would be high for new syntax. I've run into
> the awkwardness of dealing with distinct parallel tasks several times,
> and a few of the people I discussed it with were in the same boat, so
> I wrote up this proposal thinking it might have a wide appeal. The
> proposed syntax desugars via a relatively simple transformation but
> encourages developers to reason about the problem in a completely
> different way that I'd argue is more intuitive. Whether the committee
> agrees and thinks it justifies a new syntax remains to be seen, but
> either way I'm excited to see where this discussion goes (whether it
> leads to the proposed syntax, to some other syntax, or to somewhere
> else entirely).
>
> As a side note: thank you to everyone for the thoughtful questions and
> responses, I had no idea what to expect from this thread and it's gone
> better than I could've hoped for. Thank you for not immediately
> shooting down a proposal that looks similar to other proposals before
> it.
>
> On Wed, Nov 20, 2019 at 7:36 PM Isiah Meadows <[hidden email]> wrote:
> >
> > Just FYI, I previously suggested a couple things substantially more
> > flexible than this [1] [2] (originated from this [3]), and it mostly
> > fell flat due to being highly premature. Anything exclusive to
> > promises is unlikely to win as library methods exist for basically all
> > use cases and from my experience, committee members are in general
> > very hesitant to add syntax for anything that doesn't pay for itself
> > well. Similar questions have come up a few times in the past, too, and
> > I've commented on two of them. [4] [5]
> >
> > If anything, I don't feel we know the problem space well enough, and
> > the language lacks the primitives needed to really dig into it. (This
> > is why I came up with my generator forking strawman. [6])
> >
> > [1]: https://github.com/isiahmeadows/non-linear-proposal
> > [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
> > [3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
> > [4]: https://esdiscuss.org/topic/stream-async-await
> > [5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
> > [6]: https://github.com/isiahmeadows/proposal-generator-fork
> >
> > -----
> >
> > Isiah Meadows
> > [hidden email]
> > www.isiahmeadows.com
> >
> > On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:
> > >
> > > ...strike that, I misread the "but that still waits for the async
> > > functions to complete" part. So what you're proposing is that
> > > everything functions normally inside the curly braces, but execution
> > > doesn't continue until all promises have resolved? So your example
> > > would work essentially like this:
> > >
> > > ```javascript
> > > const x = doSomethingAsync();
> > > const y = doSomethingElseAsync();
> > > await x, await y;
> > > // all promises are resolved by now, but
> > > // still need to use await to unbox the values
> > > someFunction(await x, await y);
> > > ```
> > >
> > > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
> > > >
> > > > >Maybe if you drop the "await" in your example:
> > > > >
> > > > >```javascript
> > > > >await.all {
> > > > >    const x = doSomethingAsync();
> > > > >    //x is just the promise here
> > > > >}
> > > > >```
> > > > >
> > > > >...but that still waits for the async functions to complete, I think it would
> > > > >cause fewer bugs and would seem to still satisfy the motivation?
> > > >
> > > > It doesn't seem like the `await.all` block is doing anything in that
> > > > case. That code seems equivalent to this:
> > > >
> > > > ```javascript
> > > > const x = doSomethingAsync();
> > > > myFunction(await x)
> > > > ```
> > > >
> > > > >```javascript
> > > > >await.all {
> > > > >  const x = await doSomethingAsync();
> > > > >  //x is still undefined here!
> > > > >}
> > > > >```
> > > >
> > > > You bring up a good point about scoping and race conditions. It's a
> > > > little tricky since the curly braces create a block scope but none of
> > > > the parallel statements should be allowed to access each-other's
> > > > variables, it's almost like each statement should have its own scope.
> > > > Maybe it'd be better to have a syntax that ensures a set of curly
> > > > braces for each parallel task? Async do-expressions could be a good
> > > > solution (assuming they'd work kind of like an async IIFE):
> > > >
> > > > ```javascript
> > > > async function initialize() {
> > > >   let foo, bar, baz;
> > > >   await Promise.all([
> > > >     async do { foo = (await request('foo.json')).data },
> > > >     async do { bar = (await request('bar.json')).data },
> > > >     async do { baz = (await request('baz.json')).data },
> > > >   ]);
> > > >   render(foo, bar, baz);
> > > > }
> > > > ```
> > > >
> > > > (this is also a less drastic syntax change that piggybacks on an
> > > > existing proposal)
> > > >
> > > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > > 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.
> > > > >
> > > > > kind regards,
> > > > >  Bergi
> > > > > _______________________________________________
> > > > > es-discuss mailing list
> > > > > [hidden email]
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > _______________________________________________
> > > es-discuss mailing list
> > > [hidden email]
> > > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Naveen Chawla
I have a solution for that:

const promises = [...]
await.all promises //returns an array of results
await.race promises //returns a single result

etc.

On Thu, 21 Nov 2019 at 09:51, manuelbarzi <[hidden email]> wrote:
AFAIK `await` can only accept an `expression` as a `Promise`, not other thing: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await

On Thu, Nov 21, 2019 at 10:46 AM Jacob Bloom <[hidden email]> wrote:
>why not just `await` as already is, but supporting an
>iterable / array of promises, as `Promise.all` already does

`await` can already accept a non-promise, so I believe that'd be
breaking syntax if `Array.prototype.then` is set. It also requires
collecting the promises in an array, which is what the proposed syntax
is trying to avoid.

On Thu, Nov 21, 2019 at 2:41 AM Jacob Bloom <[hidden email]> wrote:
>
> >Just FYI, I previously suggested a couple things substantially more
> >flexible than this
>
> Ah, thank you for bringing those proposals to my attention. I looked
> through the archives for relevant discussions but I must've missed
> them.
>
> It seems like we converged on a similar syntax for what you called
> "merging," and the idea that there ought to be a separate syntax for
> iteration. I don't know whether that means that this is the right
> solution or just the most obvious one, but either way it's encouraging
> to know that other people have the same difficulties with the current
> syntax and are thinking about the problem.
>
> >from my experience, committee members are in general
> >very hesitant to add syntax for anything that doesn't pay for
> >itself well
>
> Yeah, I figured the bar would be high for new syntax. I've run into
> the awkwardness of dealing with distinct parallel tasks several times,
> and a few of the people I discussed it with were in the same boat, so
> I wrote up this proposal thinking it might have a wide appeal. The
> proposed syntax desugars via a relatively simple transformation but
> encourages developers to reason about the problem in a completely
> different way that I'd argue is more intuitive. Whether the committee
> agrees and thinks it justifies a new syntax remains to be seen, but
> either way I'm excited to see where this discussion goes (whether it
> leads to the proposed syntax, to some other syntax, or to somewhere
> else entirely).
>
> As a side note: thank you to everyone for the thoughtful questions and
> responses, I had no idea what to expect from this thread and it's gone
> better than I could've hoped for. Thank you for not immediately
> shooting down a proposal that looks similar to other proposals before
> it.
>
> On Wed, Nov 20, 2019 at 7:36 PM Isiah Meadows <[hidden email]> wrote:
> >
> > Just FYI, I previously suggested a couple things substantially more
> > flexible than this [1] [2] (originated from this [3]), and it mostly
> > fell flat due to being highly premature. Anything exclusive to
> > promises is unlikely to win as library methods exist for basically all
> > use cases and from my experience, committee members are in general
> > very hesitant to add syntax for anything that doesn't pay for itself
> > well. Similar questions have come up a few times in the past, too, and
> > I've commented on two of them. [4] [5]
> >
> > If anything, I don't feel we know the problem space well enough, and
> > the language lacks the primitives needed to really dig into it. (This
> > is why I came up with my generator forking strawman. [6])
> >
> > [1]: https://github.com/isiahmeadows/non-linear-proposal
> > [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
> > [3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
> > [4]: https://esdiscuss.org/topic/stream-async-await
> > [5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
> > [6]: https://github.com/isiahmeadows/proposal-generator-fork
> >
> > -----
> >
> > Isiah Meadows
> > [hidden email]
> > www.isiahmeadows.com
> >
> > On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:
> > >
> > > ...strike that, I misread the "but that still waits for the async
> > > functions to complete" part. So what you're proposing is that
> > > everything functions normally inside the curly braces, but execution
> > > doesn't continue until all promises have resolved? So your example
> > > would work essentially like this:
> > >
> > > ```javascript
> > > const x = doSomethingAsync();
> > > const y = doSomethingElseAsync();
> > > await x, await y;
> > > // all promises are resolved by now, but
> > > // still need to use await to unbox the values
> > > someFunction(await x, await y);
> > > ```
> > >
> > > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
> > > >
> > > > >Maybe if you drop the "await" in your example:
> > > > >
> > > > >```javascript
> > > > >await.all {
> > > > >    const x = doSomethingAsync();
> > > > >    //x is just the promise here
> > > > >}
> > > > >```
> > > > >
> > > > >...but that still waits for the async functions to complete, I think it would
> > > > >cause fewer bugs and would seem to still satisfy the motivation?
> > > >
> > > > It doesn't seem like the `await.all` block is doing anything in that
> > > > case. That code seems equivalent to this:
> > > >
> > > > ```javascript
> > > > const x = doSomethingAsync();
> > > > myFunction(await x)
> > > > ```
> > > >
> > > > >```javascript
> > > > >await.all {
> > > > >  const x = await doSomethingAsync();
> > > > >  //x is still undefined here!
> > > > >}
> > > > >```
> > > >
> > > > You bring up a good point about scoping and race conditions. It's a
> > > > little tricky since the curly braces create a block scope but none of
> > > > the parallel statements should be allowed to access each-other's
> > > > variables, it's almost like each statement should have its own scope.
> > > > Maybe it'd be better to have a syntax that ensures a set of curly
> > > > braces for each parallel task? Async do-expressions could be a good
> > > > solution (assuming they'd work kind of like an async IIFE):
> > > >
> > > > ```javascript
> > > > async function initialize() {
> > > >   let foo, bar, baz;
> > > >   await Promise.all([
> > > >     async do { foo = (await request('foo.json')).data },
> > > >     async do { bar = (await request('bar.json')).data },
> > > >     async do { baz = (await request('baz.json')).data },
> > > >   ]);
> > > >   render(foo, bar, baz);
> > > > }
> > > > ```
> > > >
> > > > (this is also a less drastic syntax change that piggybacks on an
> > > > existing proposal)
> > > >
> > > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > > 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.
> > > > >
> > > > > kind regards,
> > > > >  Bergi
> > > > > _______________________________________________
> > > > > es-discuss mailing list
> > > > > [hidden email]
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > _______________________________________________
> > > es-discuss mailing list
> > > [hidden email]
> > > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Matthew Morgan
In reply to this post by Jacob Bloom
Why not just use a combination of `async`/`await` and `.then`?

```javascript
async function initialize() {
    const [foo, bar, baz] = await Promise.all([
        request('foo.json').then(t => t.data),
        request('bar.json').then(t => t.data),
        request('baz.json').then(t => t.data),
    ]);
    render(foo, bar, baz);
}
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jacob Bloom
In reply to this post by Naveen Chawla
>```javascript
>const promises = [...]
>await.all promises //returns an array of results
>await.race promises //returns a single result
>```

One of the goals of this proposal is to simplify the process of
collecting the promises in an array and then having to get them out of
another array.

>Why not just use a combination of `async`/`await` and `.then`?

That's an okay solution, though we still end up having to maintain
"parallel lists" of promises and values, which I'm hoping to avoid.
But you can sidestep them with something like this, which isn't too
bad:

```javascript
async function initialize() {
    let foo, bar, baz;
    await Promise.all([
        request('foo.json').then(t => foo = t.data),
        request('bar.json').then(t => bar = t.data),
        request('baz.json').then(t => baz = t.data),
    ]);
    render(foo, bar, baz);
}
```

On Thu, Nov 21, 2019 at 3:29 AM Naveen Chawla <[hidden email]> wrote:

>
> I have a solution for that:
>
> const promises = [...]
> await.all promises //returns an array of results
> await.race promises //returns a single result
>
> etc.
>
> On Thu, 21 Nov 2019 at 09:51, manuelbarzi <[hidden email]> wrote:
>>
>> AFAIK `await` can only accept an `expression` as a `Promise`, not other thing: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await
>>
>> On Thu, Nov 21, 2019 at 10:46 AM Jacob Bloom <[hidden email]> wrote:
>>>
>>> >why not just `await` as already is, but supporting an
>>> >iterable / array of promises, as `Promise.all` already does
>>>
>>> `await` can already accept a non-promise, so I believe that'd be
>>> breaking syntax if `Array.prototype.then` is set. It also requires
>>> collecting the promises in an array, which is what the proposed syntax
>>> is trying to avoid.
>>>
>>> On Thu, Nov 21, 2019 at 2:41 AM Jacob Bloom <[hidden email]> wrote:
>>> >
>>> > >Just FYI, I previously suggested a couple things substantially more
>>> > >flexible than this
>>> >
>>> > Ah, thank you for bringing those proposals to my attention. I looked
>>> > through the archives for relevant discussions but I must've missed
>>> > them.
>>> >
>>> > It seems like we converged on a similar syntax for what you called
>>> > "merging," and the idea that there ought to be a separate syntax for
>>> > iteration. I don't know whether that means that this is the right
>>> > solution or just the most obvious one, but either way it's encouraging
>>> > to know that other people have the same difficulties with the current
>>> > syntax and are thinking about the problem.
>>> >
>>> > >from my experience, committee members are in general
>>> > >very hesitant to add syntax for anything that doesn't pay for
>>> > >itself well
>>> >
>>> > Yeah, I figured the bar would be high for new syntax. I've run into
>>> > the awkwardness of dealing with distinct parallel tasks several times,
>>> > and a few of the people I discussed it with were in the same boat, so
>>> > I wrote up this proposal thinking it might have a wide appeal. The
>>> > proposed syntax desugars via a relatively simple transformation but
>>> > encourages developers to reason about the problem in a completely
>>> > different way that I'd argue is more intuitive. Whether the committee
>>> > agrees and thinks it justifies a new syntax remains to be seen, but
>>> > either way I'm excited to see where this discussion goes (whether it
>>> > leads to the proposed syntax, to some other syntax, or to somewhere
>>> > else entirely).
>>> >
>>> > As a side note: thank you to everyone for the thoughtful questions and
>>> > responses, I had no idea what to expect from this thread and it's gone
>>> > better than I could've hoped for. Thank you for not immediately
>>> > shooting down a proposal that looks similar to other proposals before
>>> > it.
>>> >
>>> > On Wed, Nov 20, 2019 at 7:36 PM Isiah Meadows <[hidden email]> wrote:
>>> > >
>>> > > Just FYI, I previously suggested a couple things substantially more
>>> > > flexible than this [1] [2] (originated from this [3]), and it mostly
>>> > > fell flat due to being highly premature. Anything exclusive to
>>> > > promises is unlikely to win as library methods exist for basically all
>>> > > use cases and from my experience, committee members are in general
>>> > > very hesitant to add syntax for anything that doesn't pay for itself
>>> > > well. Similar questions have come up a few times in the past, too, and
>>> > > I've commented on two of them. [4] [5]
>>> > >
>>> > > If anything, I don't feel we know the problem space well enough, and
>>> > > the language lacks the primitives needed to really dig into it. (This
>>> > > is why I came up with my generator forking strawman. [6])
>>> > >
>>> > > [1]: https://github.com/isiahmeadows/non-linear-proposal
>>> > > [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
>>> > > [3]: https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
>>> > > [4]: https://esdiscuss.org/topic/stream-async-await
>>> > > [5]: https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
>>> > > [6]: https://github.com/isiahmeadows/proposal-generator-fork
>>> > >
>>> > > -----
>>> > >
>>> > > Isiah Meadows
>>> > > [hidden email]
>>> > > www.isiahmeadows.com
>>> > >
>>> > > On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <[hidden email]> wrote:
>>> > > >
>>> > > > ...strike that, I misread the "but that still waits for the async
>>> > > > functions to complete" part. So what you're proposing is that
>>> > > > everything functions normally inside the curly braces, but execution
>>> > > > doesn't continue until all promises have resolved? So your example
>>> > > > would work essentially like this:
>>> > > >
>>> > > > ```javascript
>>> > > > const x = doSomethingAsync();
>>> > > > const y = doSomethingElseAsync();
>>> > > > await x, await y;
>>> > > > // all promises are resolved by now, but
>>> > > > // still need to use await to unbox the values
>>> > > > someFunction(await x, await y);
>>> > > > ```
>>> > > >
>>> > > > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <[hidden email]> wrote:
>>> > > > >
>>> > > > > >Maybe if you drop the "await" in your example:
>>> > > > > >
>>> > > > > >```javascript
>>> > > > > >await.all {
>>> > > > > >    const x = doSomethingAsync();
>>> > > > > >    //x is just the promise here
>>> > > > > >}
>>> > > > > >```
>>> > > > > >
>>> > > > > >...but that still waits for the async functions to complete, I think it would
>>> > > > > >cause fewer bugs and would seem to still satisfy the motivation?
>>> > > > >
>>> > > > > It doesn't seem like the `await.all` block is doing anything in that
>>> > > > > case. That code seems equivalent to this:
>>> > > > >
>>> > > > > ```javascript
>>> > > > > const x = doSomethingAsync();
>>> > > > > myFunction(await x)
>>> > > > > ```
>>> > > > >
>>> > > > > >```javascript
>>> > > > > >await.all {
>>> > > > > >  const x = await doSomethingAsync();
>>> > > > > >  //x is still undefined here!
>>> > > > > >}
>>> > > > > >```
>>> > > > >
>>> > > > > You bring up a good point about scoping and race conditions. It's a
>>> > > > > little tricky since the curly braces create a block scope but none of
>>> > > > > the parallel statements should be allowed to access each-other's
>>> > > > > variables, it's almost like each statement should have its own scope.
>>> > > > > Maybe it'd be better to have a syntax that ensures a set of curly
>>> > > > > braces for each parallel task? Async do-expressions could be a good
>>> > > > > solution (assuming they'd work kind of like an async IIFE):
>>> > > > >
>>> > > > > ```javascript
>>> > > > > async function initialize() {
>>> > > > >   let foo, bar, baz;
>>> > > > >   await Promise.all([
>>> > > > >     async do { foo = (await request('foo.json')).data },
>>> > > > >     async do { bar = (await request('bar.json')).data },
>>> > > > >     async do { baz = (await request('baz.json')).data },
>>> > > > >   ]);
>>> > > > >   render(foo, bar, baz);
>>> > > > > }
>>> > > > > ```
>>> > > > >
>>> > > > > (this is also a less drastic syntax change that piggybacks on an
>>> > > > > existing proposal)
>>> > > > >
>>> > > > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <[hidden email]> wrote:
>>> > > > > >
>>> > > > > > Hello!
>>> > > > > >
>>> > > > > > > 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.
>>> > > > > >
>>> > > > > > kind regards,
>>> > > > > >  Bergi
>>> > > > > > _______________________________________________
>>> > > > > > es-discuss mailing list
>>> > > > > > [hidden email]
>>> > > > > > https://mail.mozilla.org/listinfo/es-discuss
>>> > > > _______________________________________________
>>> > > > es-discuss mailing list
>>> > > > [hidden email]
>>> > > > https://mail.mozilla.org/listinfo/es-discuss
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

manuelbarzi
In reply to this post by Naveen Chawla
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`.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Naveen Chawla
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 <[hidden email]> 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`.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123