<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">I think non determinism in code increases the probability of bugs.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Nov 2019, 23:42 Jacob Bloom, <<a href="mailto:mr.jacob.bloom@gmail.com">mr.jacob.bloom@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>This [current] structure is also just fundamentally different from working<br>
>>serially in async/await and it forces you to reason about the problem in a<br>
>>specific way. This doesn't appear to be a conscious decision to force good<br>
>>code practices<br>
><br>
>Actually I'd argue that it is. Doing stuff concurrently is fundamentally<br>
>different from doing it serially, and should be reasoned about every time you<br>
>use it.<br>
<br>
I agree that parallelism is different and should be handled with care,<br>
but I don't think it follows that the best way to reason about<br>
parallelism is the way that `Promise.all` encourages. Making something<br>
more complicated doesn't necessarily mean you'll do a better job of<br>
reasoning about it.<br>
<br>
If you think the proposed syntax encourages poorly-reasoned-about<br>
code, I'm open to iterating on it to find a syntax that works with the<br>
developer to handle parallelism in a safe way, and also doesn't<br>
require them to write too much boilerplate code.<br>
<br>
On Thu, Nov 21, 2019 at 3:16 PM Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" target="_blank" rel="noreferrer">naveen.chwl@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> On Thu, 21 Nov 2019 at 18:29, manuelbarzi <<a href="mailto:manuelbarzi@gmail.com" target="_blank" rel="noreferrer">manuelbarzi@gmail.com</a>> wrote:<br>
>>><br>
>>> I have a solution for that:<br>
>>><br>
>>> const promises = [...]<br>
>>> await.all promises //returns an array of results<br>
>>> await.race promises //returns a single result<br>
>><br>
>><br>
>> well, my proposal is exactly that, but doing `await.all` by default with just `await`.<br>
</blockquote></div>