Omitting the "await" would not suffice for the original use case of
"await": you need to know it actually completed before you continue to the
code *after* the "for" loop. It would also unleash unbounded concurrency
which usually doesn't end well.
It takes us back to:
"Sometimes my code works, sometimes it doesn't, I'm not sure why. Some kind
of timing thing?"
In my experience, the developers who try that approach have a terrible time
debugging their code later. This is why the ability to write "for...of"
loops with "await" has been such a big win for junior JavaScript developers.
As for variables outside the loop, they actually would behave reasonably.
For instance, this code would yield sensible results:
```js
const interval = setInterval(progressDisplay, 250);
let progress = 0;
for (const piece of pieces concurrency 5) {
await db.insert(piece);
progress++;
}
clearInterval(interval);
function progressDisplay() {
console.log(progress + ' of ' + pieces.length + ' completed');
}
```
Even in more complex cases, keep in mind that this is just suspension via
"await", not preemptive multitasking, so the side effects are not that
strange.
Can you give an example of a situation where this would not behave
reasonably?
I can see that my proposal would be stronger if I removed "concurrently"
and kept only "concurrency N". That is the feature I really wanted, and
including "concurrently" was just a gesture to completeness but as others
have pointed out, it's not a completeness we want.
The only place unbounded concurrency really tends to make sense is when you
don't have a giant array of things to process - you have a handful of
predetermined tasks that you know can run concurrently. I can picture a
language feature for that, but it wouldn't involve "for...of" loops (:
On Sat, Sep 7, 2019 at 7:51 AM Naveen Chawla <naveen.c...@gmail.com> wrote:
> In my mind there is a cognitive load cost in adding language constructs
> (unless they significantly otherwise reduce cognitive load). In this case,
> I find omitting the "await" would suffice for a lot of people, and for
> those who want the loop to conceptually "hang" until all are completed
> (which I find strange in of itself), I think synchronously collecting the
> operations then doing a Promise.all is more understandable to a reader. Can
> you imagine explaining a for loop that doesn't behave linearly, e.g.
> imagine you have a variable outside the loop that is being modified on each
> iteration - the whole thing would go haywire. Especially compared to
> building an array followed by a Promise.all.
>
> In my mind, the whole point of "await async" is to linearize asynchronous
> programming, so that logical flow that happens to be asynchronous is
> trivial to reason about, and read. In my mind the "concurrent" proposal
> jeopardises that.
>
> On Fri, 6 Sep 2019 at 22:05, Tom Boutell <t...@apostrophecms.com> wrote:
>
>> > Can someone tell me exactly how just omitting "await" doesn't broadly
>> achieve the "concurrency" objective?
>>
>> Omitting "await" gives us no assurance that all of the iterations
>> completed prior to exit from the "for...of" loop.
>>
>> My proposal should have specified that regardless of whether "concurrency
>> N" or "concurrent" is used, the loop will not exit until all of the items
>> have successfully executed the loop body.
>>
>> > It could be probably added as a Promise.all(iterable, concurrency?)
>>
>> While this would be a useful extension to Promise.all and might be part
>> of the underlying implementation of the language feature, this does not
>> meet the goal of avoiding the cognitive load of shifting gears from the
>> "async/await" pattern to thinking overtly about promises. There are similar
>> implementations, such as the one in Bluebird, but the goal of the language
>> feature is to expand the set of problems that can be solved without the
>> cognitive load of collecting async function return values and then awaiting
>> a library function that operates on them.
>>
>> My own belief is that the percentage of "await-friendly" use cases for
>> asynchronous programming that come up for most developers is pretty close
>> to 90%, and that a syntax for specifying concurrency would take it the rest
>> of the way there, and be much appreciated by the developer who has written
>> the "for...of { await ... }" loop and now wants to improve the performance
>> in a simple way that is also likely to be safe (bounded concurrency).
>>
>> --
>> Chief Software Architect
>> Apostrophe Technologies
>> Pronouns: he / him / his
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
--
Chief Software Architect
Apostrophe Technologies
Pronouns: he / him / his
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
