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

171–180 of 242 posts

Re: I Avoid Async/Await

#171

Post by gompertz »

gotaquestion wrote: post #164
chmod775 wrote: post #24

First off, async/await is promises. It's merely syntactic sugar. The point of async/await is not to never have the word "Promise" appear in your code. It's also not meant to be universally better than using Promises bare-bones. A lot of the argument appears to be the author extrapolating from his own lack of familiarity to others: "We are taught", "our minds", etc. I can easily construe some hypothetical person with…

> A lot of the argument appears to be the author extrapolating from his own lack of familiarity to others This is literally 97.5% of all tech blogs, and a disappointing amount of content on HN front page. I feel bad for the author. Nothing like asserting your ignorance on a blog. There's a time and a place for literally every language construct.

Agreed, and I think some authors need to be more humble. If a construct or design choice exists, its far more likely someone (or a team) spent hundreds more hours intentionally reasoning for its existence in the first place; over your passive duration of usage.

Re: I Avoid Async/Await

#172

Post by daxfohl »

kareemsabri wrote: post #47

The premise of this article seems flawed. We don't "code in a synchronous mindset" when we use async/await. I would expect most programmers are aware, after a 5 minute google search, that there is an asynchronous process happening and we need to ensure no execution after that line occurs until that process has resolved, hence we use await. If you know what it is doing, it's not complicated at all. It's identical to p…

Ultimately the problem of potentially missed opportunities for parallelism there in regular sync code too. If we take the author's point seriously, we should all be programming in a language that requires explicit continuations everywhere just to guard against accidentally serializing things.

Re: I Avoid Async/Await

#173

Post by noahtallen »

whatdidiexpect2 wrote: post #158
chmod775 wrote: post #24

First off, async/await is promises. It's merely syntactic sugar. The point of async/await is not to never have the word "Promise" appear in your code. It's also not meant to be universally better than using Promises bare-bones. A lot of the argument appears to be the author extrapolating from his own lack of familiarity to others: "We are taught", "our minds", etc. I can easily construe some hypothetical person with…

It’s just another willfully ignorant post by a mediocre JavaScript developer. Are you shocked?

No post body was provided.

Re: I Avoid Async/Await

#174

Post by yourad_io »

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?

Sometimes you want to do things sequentially, so for..of x { await } is the way to go

If you want parallelism: await Promise.all(x.map(...))

Re: I Avoid Async/Await

#175

Post by STRML »

> a try block in JavaScript immediately opts that section of code out of many engine optimizations as the code can no longer be broken down into determinative pieces

This isn't true and the dependent clause doesn't even make sense.

Yes, V8 had trouble optimizing try/catch back in the Crankshaft days. But those days are long gone, and major engines (V8/TurboFan, JSC, and Mozilla's latest *Monkey) handle this construct quite well. Even if this were not true, it would be meaningless, as this is simply syntactic sugar over `Promise#catch()`, which you would be using anyway.

Re: I Avoid Async/Await

#176

Post by imbnwa »

Async/Await covers the 80% of use cases for async logic in JS. Most people aren't really using promises as multicast references. They don't call `then` in one place, hang on to the promise reference, then call `then` again somewhere else (perhaps to represent a cached value); they call `then` once on the reference because it's just a moment in a composite operation.

It's for this reason that I think this library[0] is the more appropriate abstraction for that same 80% of use-cases, as its more memory efficient since you can represent the same composite operation that generates multiple promise references with a single object (a unicast reference instead). I haven't learned Rust but apparently the author bases this on Rust's ownership principle.

[0]https://github.com/mitranim/posterus

Re: I Avoid Async/Await

#177

Post by yourad_io »

Aeolun wrote: post #19
zebracanevra wrote: post #7

If you're doing nothing in between your async calls, using .then/.catch might be simpler. As soon as you need to introduce local variables and complex control structures, not having shared closures between your .then methods becomes extremely limiting. Hence, the async/await sugar. About having to add await to ensure your error is handled with the try catch — not putting an await before a promise is something I use a…

> Being able to store tasks/promises and reuse/await them later is a clear advantage This sounds like horrible spaghetti. I can understand you might need to do it in exceptional circumstances, but I wouldn’t make a habit of it.

Graceful shutdown & startup are two use cases that I used this for, just today.

When my express server gets a SIGTERM I want it to stop accepting new requests but finish pending requests before exiting.

Likewise during startup, the HTTP server is currently up before all resources are available - DB backends and the like. So I await a .ready promise before all requests iff we are not inited.

It can be abused into spaghetti for sure, but actual use cases are not that exotic imho

Re: I Avoid Async/Await

#178

Post by zkldi »

recursivedoubts wrote: post #80

I work on a web scripting language that abstracts away asyc/await: https://hyperscript.org/docs/#async we call it "Async Transparency" It lets you write code like this: fetch /some-url as json put the result's content into me where fetch is an async call, but you don't have to await it or anything or mark it as being an async fuction, whathaveyou effectively, we de-color the language: https://journal.stuffwithstuff.c…

How would you allow running the fetches in

    fetch /some-url as json
    fetch /some-other-url as json

    do_stuff_with(result1, result2)
in parallel?

Re: I Avoid Async/Await

#179

Post by albedoa »

Aeolun wrote: post #86
bin_bash wrote: post #61

Earlier quoted context omitted.

I prefer async/await but this is a contrived example. For starters you can just write: const myfunc = () => new Promise(resolve => resolve()) or Promise.resolve()

const myfunc = () => new Promise(resolve => resolve()) Is there anyone that actually likes this structure? I find it really hard to reason about what a line like this does. What is the upper limit on double arrows in one line?

Your gripe is that there are two arrows on one line? The second is an argument to the promise constructor. You should be able to reason about this line easily.

Re: I Avoid Async/Await

#180

Post by z3t4 »

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 avoid Promises (and thus async/await) in JS because the promise will capture all future errors, and if you forget to add a .catch, that error will never surface. Promises make asynchronous code more complicated. Async/await however get rid of a lot of the complicated syntax, so when I do not care about errors (eg. errors are exceptions) I use async/await because of easier control flow.

Post reply on HN