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

191–200 of 242 posts

Re: I Avoid Async/Await

#191

Post by stareatgoats »

garyrob wrote: post #149
eurasiantiger wrote: post #110

Earlier quoted context omitted.

Many devs unnecessarily nest Promises like that. async function getData() { return new Promise((resolve) => { const res = fetch(…); resolve(res); }); } The response above is wrapped in THREE different Promises! One from fetch, one manually created, and one implicitly created by `async`. The code above behaves exactly the same as function getData() { return fetch(…); } or even just fetch(…);

I'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?

The whole async/await paradigm (including promises) is trying to fit square pegs into round holes (trying to make async processes look like they are synchronous). Just look at the comments on this page; even though async/await/promises have been around for years they are still causing difficulties for even the most experienced devs.

It doesn't mean it can't be mastered, it can, but the whole paradigm is so fraught with pitfalls and conceptual difficulties that an codebase that uses it in any extensive way will forever be unstable. The whole thing is supposed to help against callback hell, but that can be better solved by a simple thenable object.

Not a popular opinion I know, but there you go.

Re: I Avoid Async/Await

#192

Post by jjnoakes »

_ZeD_ wrote: post #185
imtringued wrote: post #99

Earlier quoted context omitted.

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.

This is only partly true, but misses the point.

Consider that 'save()' might do multiple steps under the covers (network, database, localstorage, whatever). Allowing those steps to run interleaved, if necessary (with Promise.all), might be quite different from serializing the 'save()' calls completely in the caller.

So while it is true that neither is truly parallel in the "parallel vs concurrent" sense, it is not true that the "sequential"/"concurrent" execution of both styles has the same performance characteristics.

Re: I Avoid Async/Await

#193

Post by jseban »

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…

Errors are an important part of the control flow, if you are doing UI programming, which is what Javascript is made for.

Re: I Avoid Async/Await

#194

Post by jseban »

divan wrote: post #102
jffry wrote: post #98

Earlier quoted context omitted.

Since this article is specifically about Javascript: I think the implementation of async/await in the language is heavily constrained by a desire for backwards compatibility. After all, async/await is ultimately promises all the way down, so you can happily write code and let a compiler turn it into ES5 that runs anywhere. If instead JS allowed you to shunt arbitrary function calls off into their own threads, then yo…

To be honest, I find promises even worse concept for concurrent programming. At least I never think about things and behaviour in terms of "objects that will yield value in the future". To use promises I need to build a layer of conversion between "how my brain thinks about world" and "passing around promises" – and that's just textbook accidental complexity and unneeded cognitive load. The least cognitively expensiv…

Me too, there is no concurrent programming in Javascript. It's a continuation passing style language and a single threaded runtime, I wish people would just spend a little time learning how that works and normal javascript will make a lot of sense and not look "yucky" anymore. And you will realise how great of a fit that is for UI programming and reacting to events from the user, where you don't have to think about blocking the UI thread like you need to in Java.

Re: I Avoid Async/Await

#195

Post by RedShift1 »

matt-attack wrote: post #190
linkdd wrote: post #103

Earlier quoted context omitted.

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.

No, why would there be?

Re: I Avoid Async/Await

#196

Post by matt-attack »

RedShift1 wrote: post #195
matt-attack wrote: post #190

Earlier quoted context omitted.

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

No, why would there be?

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.

Re: I Avoid Async/Await

#197

Post by bilater »

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.

Yup - I prefer async/await but that was actually a good example on optimizing multiple promises I had not though of before.

Re: I Avoid Async/Await

#198

Post by RedShift1 »

matt-attack wrote: post #196
RedShift1 wrote: post #195

Earlier quoted context omitted.

No, why would there be?

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.

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.

Re: I Avoid Async/Await

#199

Post by phendrenad2 »

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…

> 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

Sounds like you didn't understand the point of the article. Unfortunately, you're arguing against something the author never said, the author never said that async/await weren't promises. You just got stuck on the fact that the author used the term "promise" for the non-async/await style of code. I understood what the author meant, anyway.

> "People can mess this up" was never an argument

Unfortunately, you're arguing against something the author never said here, also. The author is saying that non-async/await code is better code than async/await. Not that "people can mess this up" or something.

Re: I Avoid Async/Await

#200

Post by justsomeuser »

I don’t think of async await as “making async code act like sync code”.

I see it as adding meta data to a function type (async) and allowing you to attach the result to a given function scope (await).

The key utility of this is to allow you to use functions as a unit of composition, allowing you to leverage their already built tooling (IDE jump to function, stack frame based debugging, input and output types (in:args -> out:return).

Messaging runtimes like Golang and Erlang use an additional composition unit (channels and mailboxes), and do not allow you to follow the “tree of functions” paradigm like async await does. These result in having to follow a network graph of messages and nodes to find out what will happen.

You need to understand you are dealing with an event loop before you use async await. I think this is the issue the author is raising.

Post reply on HN