>>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 <[email protected]> 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 <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
