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

101–110 of 242 posts

Re: I Avoid Async/Await

#101

Post by gorjusborg »

nameisname wrote: post #90
BenoitEssiambre wrote: post #71

Earlier quoted context omitted.

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 awai…

Exactly. Async/await just an alternative way to represent a promise chain.

My feeling is that mixing the use of promise chains and async/await can make code hard to follow, so I ask colleages to not mix them in the same function.

Sure, async/await is syntactic sugar for a generator that chains promises into a promise chain for you. Not sure why you'd care. That is an implementation detail that never gets exposed to the user.

The only time I feel that promise chains are better async/await is when treating Promise as a monad https://blog.bitsrc.io/out-with-async-await-and-in-with-prom...

Re: I Avoid Async/Await

#102

Post by divan »

jffry wrote: post #98
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 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 expensive model for concurrent programming is CSP, precisely because it fits into how we humans reason about world.

Re: I Avoid Async/Await

#103

Post by linkdd »

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.

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

Re: I Avoid Async/Await

#104

Post by todd3834 »

Very strange to compare async/await to promises when it is just a part of promises. There are rare situations where promise callbacks might be easier to read but those are more edge cases and a matter of personal preference.

Re: I Avoid Async/Await

#105

Post by BigJono »

pawelmurias wrote: post #45
unityByFreedom wrote: post #30

I'll take "blog posts asserting silly things for clicks" for $100, Alex. All of this author's examples using .then() are single-line functions. Seems contrived to suit their opinion. Just use the right tool for the job.

Just typical medium garbage with constructed examples to claim that their artificial view point isn't that stupid.

You pretty much just described half the TC-39 proposals. I wish this shit was limited to noobs on Medium.

Re: I Avoid Async/Await

#106

Post by gorjusborg »

jrwr wrote: post #57
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 avoid Javascript outright because async/await/promise is confusing to me. I blame it on being a PHP Programmer and likes things to run serially.

I felt the same way coming from a threaded language.

Learning the event loop, then promises, then async/await is a must. Today, you probably should throw typescript on top.

A steep learning curve just to get back to a typed language that can do things concurrently.

You do get used to it, but it is a mess of stuff.

Re: I Avoid Async/Await

#108

Post by eurasiantiger »

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?

It’s the cleanest way to wrap a event-emitting library, for example. async/await is not applicable in such a case where resolve needs to be explicitly called in a callback.

    async function process() {
      return new Promise((resolve, reject) => {
        emitter.on(”error”, (err) => reject(err));
        emitter.on(”end”, (result) => resolve(result));
        emitter.start();
      });
    }
async is not strictly needed here, but I find it a good practice to use it on functions which immediately return a Promise anyway.

Re: I Avoid Async/Await

#109

Post by codeflo »

Some language features aren’t aimed at toy examples, and if that’s the scope of your thinking, you won’t see the point.

For example, I like how the catch block is just a single function call to handleErrorSomehow — which would be totally fine for an example, if it weren’t for the fact that the author makes a special note of how convenient it is that the Promise variant reduces to just .catch(handleErrorSomehow). Suuuper-realistic.

I should probably admit that I also didn’t completely see the point of async/await — this was years ago in C# — until I first had a chance to use it inside a complex loop of some kind. I think it’s a good exercise to try manually desugaring such an example. It really makes you appreciate what the compiler’s doing for you in these cases.

Re: I Avoid Async/Await

#110

Post by eurasiantiger »

aGHz wrote: post #73
michaelsalim wrote: post #67

Earlier quoted context omitted.

Care to give some examples of the helpers? I always just use new Promise()

You really end up creating promises manually, the vast majority are downstream from an IO call like fetch() or a database query.

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(…);
Post reply on HN