Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Avoid Async/Await

uniqname.medium.com

Post reply on HN
Print view View original

181–190 of 242 posts

Re: I Avoid Async/Await

#181

Post by aGHz »

tehbeard wrote: post #76
aGHz wrote: post #74

Earlier quoted context omitted.

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

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...

This is correct, I wasn't paying attention.

Re: I Avoid Async/Await

#182

Post by z3t4 »

z3t4 wrote: post #180

I understand there are two sides/groups here: 1) Those who think errors are important to control flow, and 2) Those who think errors are exceptions to control flow. If you are in group 2 both Promises and async/await will give you neat and simple code. But if you are in group 1 Promises and async/await will be really complicated and ugly because each await will be inside a try/catch. Because I'm in group 1, I try to…

Those who think of errors as exceptions can further be divided into group 2a) Those who prefer Promises syntax. And group 2b) Those who prefer async/await syntax.

Also don't forget about co-routines:

    co(function* () {
        var user = yield getUser();
        var comments = yield getComments(user);
    });
Just replace "co(" with async, and yield with await, and you'll have async/await.

Re: I Avoid Async/Await

#183

Post by jseban »

saimiam wrote: post #68
zazibar wrote: post #39

Now maybe it’s just my familiarity with Promises, but I look at the third example and I can quickly see an opportunity. This entire article is built around the author's ignorance and could easily be summarised as "I avoid async/await syntax because I'm more familiar with promises". The author doesn't even appear to understand that async/await is syntactic sugar for promises.

I didn’t read the article like that at all. How would you handle two asynchronous saves which can happen in parallel without using a Promise.all? Don’t think you can…and that’s pretty much the entire point of the article. Async/await is useless unless you are willing to serialize your calls defeating the entire point of async code.

Promises are also just syntactic sugar to make your code look more synchronous, you can do everything with plain callbacks. Which I find ironic with the article that he argues against that but still just stops at the next turtle, instead of following his own advice and actually learning how Javascript and it's runtime works.

Re: I Avoid Async/Await

#185

Post by _ZeD_ »

imtringued wrote: post #99
zazibar wrote: post #39

Now maybe it’s just my familiarity with Promises, but I look at the third example and I can quickly see an opportunity. This entire article is built around the author's ignorance and could easily be summarised as "I avoid async/await syntax because I'm more familiar with promises". The author doesn't even appear to understand that async/await is syntactic sugar for promises.

What the author wants is something like this: async { save() save() } catch (Exception e) { console.log("Handle error") } async does not deliver this at all.

what the author wants doesn't exists because the two saves will not actually run in parallel in any case. Not with `async save(); async save();` nor with `Promise.all` nor with any callback or any other means.

the author is conflating parallel with concurrent programming.

and in (the mono-thread world of) javascript the two calls will still occurs sequentially.

Re: I Avoid Async/Await

#186

Post by jseban »

atsjie wrote: post #29

I never liked promises when they were first introduced because I never perceived this "callback hell" to be an unmanageable problem; there are excellent libraries to manage callback composition, e.g. https://caolan.github.io/async/v3/ When Promises came along I didn't feel they added much value; in fact it made things more complicated (new paradigm, harder to compose). Still, I went with it because everyone else went…

Same here, I've never had that callback hell problem either, I think it's pretty elegant actually and you can do a lot of nice refactoring by extracting callbacks into variables. And the big strength is that your programming actually looks the way that the runtime works. It just becomes confusing with another abstraction that obfuscates the way the runtime works and requires you to now have this mental translation model.

Re: I Avoid Async/Await

#187

Post by RedShift1 »

saimiam wrote: post #150
RedShift1 wrote: post #70

Earlier quoted context omitted.

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?

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.

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.

Re: I Avoid Async/Await

#189

Post by madeofpalk »

ElFitz wrote: post #166
madeofpalk wrote: post #56

Earlier quoted context omitted.

One thing I really like async/await for is you can use them in for-loops. It makes it significantly easier to do async work in what was previously very synchronous.

I thought await in loops was a big no no, unless it has changed since I last checked? Doesn’t it remove any opportunity for parallelism, making the loop take much longer than it would with a Promise.all? Or am I missing something?

You're right(ish) - the async functions would not run in parallel. But sometimes that's either fine, or I don't want them to run in parallel.

Re: I Avoid Async/Await

#190

Post by matt-attack »

linkdd wrote: post #103
aGHz wrote: post #74

Earlier quoted context omitted.

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

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).

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