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

81–90 of 242 posts

Re: I Avoid Async/Await

#81

Post by xigoi »

valenterry wrote: post #77
xigoi wrote: post #62

Earlier quoted context omitted.

How is it not?

Many reasons, for example: 1. do notation works and is used for any monadic type (e.g. lists, parsers, promises, resources like database-connection-contexts, ...) while async/await works for promises only 2. async works on the function-level and only there while do-notation can be used in any place where a normal expression can be used, including being abitrarily nested. There are more differences, but that should be…

I don't think we disagree. JavaScript should've gone with do notation precisely because it's a generalization of async/await.

Re: I Avoid Async/Await

#82

Post by jrochkind1 »

adontz wrote: post #22

I believe author misses one important point. Async/await optimizes for throughput, not latency. Use case is many lightweight tasks you want to parallel as wholes. Web APIs, web sites are usual examples. However, if you need other kind of optimizations, like two parallel saves within one request, maybe async/await is not what you need in the first place.

The performance characteristics of promises and async/await are identical, no?

Re: I Avoid Async/Await

#84

Post by robmccoll »

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 within a request because it's easier to read, write, understand, and reason about and concurrent progress across requests. The places where I can overlap I/O within a request can be manually specified. I guess this is kind of how Go works (although that's parallelism and concurrency).

Re: I Avoid Async/Await

#85

Post by valenterry »

xigoi wrote: post #81
valenterry wrote: post #77

Earlier quoted context omitted.

Many reasons, for example: 1. do notation works and is used for any monadic type (e.g. lists, parsers, promises, resources like database-connection-contexts, ...) while async/await works for promises only 2. async works on the function-level and only there while do-notation can be used in any place where a normal expression can be used, including being abitrarily nested. There are more differences, but that should be…

I don't think we disagree. JavaScript should've gone with do notation precisely because it's a generalization of async/await.

From the perspective of someone wanting to use the powerful do-notation, sure. But at the same time, the hurdle for many developers who just want to "use promises with ease", it would have been a steeper learning curve with much less beginner-friendly syntax.

do-notation doesn't really help to deal with promises, it even makes it harder because it is confusing at the beginning. Async/await makes using promises easier and hides problems for some time at least. I can see why they chose to use async/await.

Just to give an example: error handling with try/catch. That doesn't work with do-notation, but with async/await you can integrate it (more or less at least) and it looks like sync code.

Re: I Avoid Async/Await

#86

Post by Aeolun »

bin_bash wrote: post #61
eurasiantiger wrote: post #32

Earlier quoted context omitted.

This, very much this. async function() {} is much nicer than function() { return new Promise( (resolve) => resolve() ) }

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?

Re: I Avoid Async/Await

#87

Post by bin_bash »

wildrhythms wrote: post #72
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()

As soon as you need to chain Promises, this gets very annoying and you quickly find yourself in a nested callback hell.

If you’re nesting “new Promise” you’re almost certainly doing it wrong. This is for generating new promises not executing them.

Re: I Avoid Async/Await

#88

Post by igemnace »

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.

Just because you use async/await doesn't mean you can't use Promise.all.

In fact, my immediate intuition with the await examples was to parallelize with Promise.all.

    await Promise.all([/* build promises */]);

Re: I Avoid Async/Await

#89

Post by bin_bash »

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?

here's a real world example I use all the time:

    const wait = (ms = 500) => new Promise(resolve => setTimeout(resolve, ms));
then:

    async function () {
      await wait(1000);
    }
Perhaps it's hard to grok but it sure is a handy one-liner.

Of course in newer versions of node we can now do:

    import {
      setTimeout,
    } from 'timers/promises';

    await setTimeout(100);

Re: I Avoid Async/Await

#90

Post by nameisname »

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…

I don't agree with you fully. Async most certainly always returns a promise and as such can easily be combined with promise functions, like Promise.all. Your understanding of stack traces on promises is also old/uninformed. I work on an enterprise grade node app that was started back in node 0.11. Bluebird, which was what one used, offers good stack tracing and improved stack tracing has been available for async await for a few years now. Infact, I don't think I have had to go out of my way to get a decent stack trace in about a year or more now. There are certain paradigms you can adopt that keeps promise chains clean just like you would adopt with callbacks. I can't comment on if async await was implemented poorly as you are certainly more knowledgeable there with the RFC you shared.
Post reply on HN