I Avoid Async/Await

Re:I Avoid Async/Await by RedShift1 on Saturday April 16, 2022 @08:24AM (#31051746)

  const x = somethingAsync();
  const y = somethingAsyncToo();

  return  { foo: await x, bar: await y }

There is no point in returning one before the other because you need both?

[ Parent | on HN ]

Re:I Avoid Async/Await by saimiam on Saturday April 16, 2022 @12:22PM (#31053596)

I think you’re trying to recreate the semantics of Promise.all without using Promise.all.

You’re effectively saying that Promises are a better async programming paradigm than async/await…which is also what the author is saying in the article.

[ Parent | on HN ]

Re:I Avoid Async/Await by RedShift1 on Saturday April 16, 2022 @01:36PM (#31054270)

I'm not saying anything about promises vs async/await. The original comment said that you can't have 2 async things happen in parallel without Promise.all, my code snippet proves that you can.

[ Parent | on HN ]

Re:I Avoid Async/Await by aGHz on Saturday April 16, 2022 @08:33AM (#31051791)

But in JavaScript, these two awaits will not happen in parallel, you really need to await Promise.all() for that.

[ Parent | on HN ]

Re:I Avoid Async/Await by tehbeard on Saturday April 16, 2022 @08:41AM (#31051832)

You've really missed the point spectacularly of that example.

Both those promises start, and both are waited for after both have started..

That is the same as promise.all... There's just an explicit order for the wait, rather than as they resolve, but the result is the same.

Now, promise.any.... You'd have a point...

[ Parent | on HN ]

Re:I Avoid Async/Await by aGHz on Saturday April 16, 2022 @01:25PM (#31054172)

This is correct, I wasn't paying attention.

[ Parent | on HN ]

Re:I Avoid Async/Await by linkdd on Saturday April 16, 2022 @09:28AM (#31052150)

In Javascript, a Promise is started as soon as it is created. In other words, this is not the `await` that starts the Promise.

If the first await is the slowest, the second one will return immediately (like calling .then on an already resolved promise).

[ Parent | on HN ]

Re:I Avoid Async/Await by codethief on Saturday April 16, 2022 @03:28PM (#31055321)

+1 Notably, this is different in Python where promises (futures) are executed lazily, i.e. when you await them.

[ Parent | on HN ]

Re:I Avoid Async/Await by matt-attack on Saturday April 16, 2022 @01:49PM (#31054381)

Pretty sure there can be unexpected behavior if you wait too long before you do those awaits at the end.

[ Parent | on HN ]

Re:I Avoid Async/Await by RedShift1 on Saturday April 16, 2022 @02:06PM (#31054567)

No, why would there be?

[ Parent | on HN ]

Re:I Avoid Async/Await by matt-attack on Saturday April 16, 2022 @02:11PM (#31054617)

Node 16 will exit if an exception is thrown and not awaited for some finite period of time. So if your goal is to keep those promises in some cache and then resolve them later on at your leisure, you will find the entire node process will abort. There is a feature flag to restore the older behavior but it’s a pretty big gotcha.

[ Parent | on HN ]

Re:I Avoid Async/Await by RedShift1 on Saturday April 16, 2022 @02:22PM (#31054723)

There is no such finite period of time. You can call an async function and never await it.

Exception handling is something completely different. Yes, if you call an async function and do not catch the exception, Node will stop. But that is independent of having called await or not. Whether or not you await something async does not affect exception behavior.

[ Parent | on HN ]