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

91–100 of 242 posts

Re: I Avoid Async/Await

#91

Post by [deleted] »

BenoitEssiambre wrote: post #71
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…

Async/await is certainly not promises. In fact it would be much better implemented without promises as I proposed here: https://es.discourse.group/t/callback-based-simplified-async... I would even say that async/await is anti-promise, it takes the main functionality of promises, a caching layer for results and errors that allows you to add the code continuation later and elsewhere (which is a major footgun imo) and c…

[deleted]

Re: I Avoid Async/Await

#92

Post by divan »

Author mentions that async/await messes up with mental model of the code, and I think that's the most important issue with it, but it goes even deeper than described in the article.

There are no inherently async or sync functions. It's not a property of a function, rather the property of what caller does after calling a function.

Is throwing a ball an async or sync action? Well, if tennis robot machine spits one ball after another and doesn't care/wait about feedback – then it's async. If the tennis player hits the ball with a racket and puts all her/his attention into waiting/validating the result (essentially blocking) – then it's synchronous function. It's essentially an "attention" of the caller that defines sync or async.

Marking code as inherently "sync" or "async" or claiming that one functions are "hard" and others are "easy" is the single dumbest idea I've seen in computer programming. And it's insane how contagious it is - seems like languages are more often copypasting features from other, instead of designing from the first principles.

Re: I Avoid Async/Await

#93

Post by AshleysBrain »

Their promise-based error handling seems to skip over a major gotcha: if the first `save` call throws an exception, it does not get handled in the `.catch()` callback! It would require its own try-catch to handle. That is an overlooked benefit of try-catch in async functions: it handles everything, both normal exceptions and promise rejections.

Re: I Avoid Async/Await

#94

Post by [deleted] »

robmccoll wrote: post #84

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior…

[deleted]

Re: I Avoid Async/Await

#95

Post by jffry »

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.

> How would you handle two asynchronous saves which can happen in parallel without using a Promise.all?

This question doesn't make sense. Async/await is just a nicer syntax for interacting with promises. So my answer to your "gotcha" question is just:

  await Promise.all([..., ...])
There's nothing impure going on here. The majority of the time, async/await can make it much easier to see a code's control flow by getting rid of most of the Promise related cruft and callbacks.

I would call Promise.all a benefit here, as it makes it stand out where I'm doing something in parallel.

Re: I Avoid Async/Await

#96

Post by [deleted] »

aGHz wrote: post #74
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?

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

[deleted]

Re: I Avoid Async/Await

#97

Post by davidmurdoch »

robmccoll wrote: post #84

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior…

I like this idea!

Re: I Avoid Async/Await

#98

Post by jffry »

divan wrote: post #92

Author mentions that async/await messes up with mental model of the code, and I think that's the most important issue with it, but it goes even deeper than described in the article. There are no inherently async or sync functions. It's not a property of a function, rather the property of what caller does after calling a function. Is throwing a ball an async or sync action? Well, if tennis robot machine spits one ball…

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 you would need bigger changes to the engines to support that, and you couldn't back-port that to vanilla javascript.

Re: I Avoid Async/Await

#99

Post by imtringued »

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.

Re: I Avoid Async/Await

#100

Post by chmod775 »

robmccoll wrote: post #84

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior…

You might be interested in these linter rules:

https://typescript-eslint.io/rules/no-misused-promises/

https://typescript-eslint.io/rules/no-floating-promises/

They can catch some common mistakes. Of course these checks can only work reliably when you're using a typed language.

I'm still looking for one that forces me to put an await in front of every function call that returns a promise, unless I opt out.

Post reply on HN