Hacker News Reader

Comment by recursive | Hacker News Reader

The way I would write the code is never covered, and I can't tell it's because I don't understand async, or I'm secretly a genius.

The article says this is correct.

> const both = await Promise.all([ members, nonMembers ]); > return both[0].concat(both[1]);

I would have written it this way without the third promise.

> return (await members).concat(await nonMembers);

Is this wrong somehow?

View on HN

This is not wrong, it's just not parallel. That is, the second promise, inside `.concat()`, will only get created and scheduled after the `await members` will have resolved.

The point of `Promise.all` is to have every promise passed to it to start computing concurrently, likely in parallel if they e.g. start independent I/O operations.

If I follow your statement, it doesn't appear correct. JS Promises are eager, and the work underlying the promise will begin executing prior to being awaited. Await is just blocking on that execution's resolution.

    // Given:
    const fooPromise = asyncFoo();
    const barPromise = asyncBar();

    // Then this...
    await fooPromise;
    await barPromise;

    // ...is equivalent to this:
    await Promise.all([fooPromise, barPromise]);

Now, Promise.all() is useful, but it is unrelated to when computation starts.

This is true and this is the root cause of the misunderstanding from the blog. Promises execute immediately, await blocks on a promise. Promise.all and Promise.allSettled allow you to compose promises and block on a single promise instead of multiple awaits but have nothing to do with executing a promise.

The misunderstanding in the article has to do with misunderstanding when a promise is executed. It’s easy to wonder why calling await on a promise directly vs calling it on a variable containing a promise is different. The difference is promises execute immediately on creation while await blocks on a promise. So a promise that is created after an await will be executed after that awaited promise is resolved.

I can't get it, and from my experience, this is not true.

Consider:

  const x = await foo();
  await bar(x);

How can you schedule `foo()` and `bar()` in parallel, when they have an explicit data dependency?

> How can you schedule `foo()` and `bar()` in parallel, when they have an explicit data dependency?

You can't, but that's a fundamentally different scenario than what's being discussed.

I'm not super familiar with javascript, but this would be very surprising to me? The instantiation of the work should be at the issuance of the promise, after which it would be in the queue of things to be done next time control is returned to the event loop.

`await` should just return control to the event loop (ie. actually transform the remaining code into a callback). If you've issued the two promises before that happens both should be able to start operation.

As far as I know the difference here would be effectively (in very loose pseudo-code:

    fetch(first).then {
      fetch(second).then {
        doThings();
      };
    };

vs.

    a = fetch(first);
    b = fetch(second);
    a.then { b.then { doStuff(); } };

which to my understanding should do both fetches in parallel even though the resolution is not.

Looking at a bunch of articles about "how Promise.all can be implemented" it looks like this kind of recursive resolution of the promises is one of the methods that's expected to work (if not perform terribly well in the general case)?

See this SO answer for eg. as well: https://stackoverflow.com/a/46348155

May understanding can as well be wrong!

I expected `await X` to create the promise `X` when it starts executing, much like `cond_A || cond_B` only computes `cond_B` when `cond_A` has been computed and turned out falsy.

Else how the following code ever work correctly?

  const x = await foo();
  const y = await bar(x);

We cannot schedule `bar()` before we have computed its inputs.

OTOH `(await x()).concat(await y())` could speculatively compute both promises concurrently, even if it does not yet know whether the result of `x()` has a property named `concat`. I won't normally expect it, but JS is used to defy logic in many areas :-\

no, generally `await` is the fulfilment of a promise already created. `foo()` returns a promise, and then the await triggers the ceding of control to the event loop and allows the promise to progress.

In the example you've shown, it is absolutely correct that the two promises must be sequentially awaited like that. The OP is talking about a situation where there is no dependency between x and y.

This is not true, since in JS promises are dispatched as soon as they are created. So as long as you call the fetch function, it doesn't matter that you are calling `await` sequentially.

Author here: I actually tested this out after seeing someone else post the same solution, and it does run in parallel. Because the awaits don't come until after both requests have been created, the second request isn't blocked by the first.

Personally I agree that this is cleaner than the Promise.all() solution, but I also think it emphasizes just how misleading the syntax can be, given that those weighing in on this thread can't even agree what this code will do without trying it out.

I'm personally surprised that people find this misleading? I mean, in so far as any programming construct is confusing until you understand it I can see it, but fundamentally if a promise could not progress until you waited on it, it would basically become impossible to write parallel code at all -- including implementing Promise.all().

Afaik that just runs in serial, like the original example. `await` pauses execution immediately.

In all examples provided, unless you want to return them as separate promises, you must await at some point. My understanding is that calling await on a promise does not prevent other Promises from being fulfilled, it just pauses execution of the rest of the code block. For example, if you performed two web requests and then awaited a setTimeout for a few seconds, your two web request promises would likely already be resolved by the time you awaited them. Which would mean that the difference between

    await fetch
    await fetch
    concat

and

    fetch
    fetch
    concat await

is that the fetch can actually perform asynchronous web activity in the latter example.

Yes, but the first pause comes after both requests have been started.

Are you sure? It seems incongruous with my mental model, which is that the first `await`, when executed, immediately pauses execution, so the second is only dispatched when the first has resolved.

The second await does not start until the first await resolves the first promise, but that doesn't mean network activity for the second initiated request isn't still happening in the background.

Yes.

> the first `await`, when executed, immediately pauses execution

Also true, but in my code, the first `await` happens after the second `fetch()` has already begun.

This has the same problem, (await members) will happen first, only when that’s done will (await nonMembers) happen.

That seems different, and not like a problem at all.

My understanding is that `await` refers to the resolution of a promise, not its start.

Isn't it as sequential as the original code?

I don't believe so. Both promises are created before any are awaited.

Reply on news.ycombinator.com