I Avoid Async/Await • Hacker News Board

Re: I Avoid Async/Await

#121

Post by zkldi » Sat, Apr 16, 2022, 2:43 PM UTC

jrochkind1 wrote: post #82

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?

they are. async functions sre just syntactic sugar for returning promises.

Re: I Avoid Async/Await

#122

Post by RobertWHurst » Sat, Apr 16, 2022, 2:53 PM UTC

eurasiantiger wrote: post #110

aGHz wrote: post #73

Earlier quoted context omitted.

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(…);

I've been on teams working on node projects for like 15 years. I've never seen someone who understands promises or async await do that. You'd have to know nothing about what the async keyword actually does to be compelled to do that.

Re: I Avoid Async/Await

#123

Post by ninkendo » Sat, Apr 16, 2022, 3:11 PM UTC

mojuba wrote: post #117

ninkendo wrote: post #26

Earlier quoted context omitted.

You can generally do something like: Task { [weak self] in await foo() self?.bar() // self may be nil } That is, you can just make a new task which awaits on something and then does more work, and that Task can be tagged with weak self so that self can be freed.

So basically no way to do the same with await, other than of course declaring a weak local var.

If you’re await’ing a variable directly in the same scope, of course self will be retained, you’re still running inside self’s scope.

I guess I’m confused by the question… if you want to await something and allow self to be freed in the process, you can use Task{ [weak self] } and then return early. If you don’t want to return early, you can’t really release self yet, since the scope shouldn’t outlive self.

Re: I Avoid Async/Await

#124

Post by eurasiantiger » Sat, Apr 16, 2022, 3:12 PM UTC

RobertWHurst wrote: post #122

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've been on teams working on node projects for like 15 years. I've never seen someone who understands promises or async await do that. You'd have to know nothing about what the async keyword actually does to be compelled to do that.

I have seen plenty of (usually junior front-end) devs resort to exactly this kind of cargo cult coding and magical thinking.

Re: I Avoid Async/Await

#125

Post by eurasiantiger » Sat, Apr 16, 2022, 3:14 PM UTC

zkldi wrote: post #119

eurasiantiger wrote: post #108

Earlier quoted context omitted.

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…

I don't think it's a good practice, atleast if you have typescript jn your stack. It's redundant and wraps the promise in another promise.

IIRC that doesn’t actually happen if a native Promise is returned.

Re: I Avoid Async/Await

#126

Post by atsjie » Sat, Apr 16, 2022, 3:23 PM UTC

jrochkind1 wrote: post #78

atsjie wrote: post #29

I never liked promises when they were first introduced because I never perceived this "callback hell" to be an unmanageable problem; there are excellent libraries to manage callback composition, e.g. https://caolan.github.io/async/v3/ When Promises came along I didn't feel they added much value; in fact it made things more complicated (new paradigm, harder to compose). Still, I went with it because everyone else went…

The semantics of the library you link to seems fairly similar/analogous to promises to me! I'd in fact call promises themselves "an excellent library to manage callback composition", I don't see any reason to prefer the one you link over the promises api -- even if neither were built-in to JS. (And promises of course originally were not).

Your comment is a bit misleading, I doubt you looked for more than 30 seconds at that lib's documentation given the lack of detail in your response.

Just to be clear; I would never use that lib in any circumstance right now, I'd always prefer async/await for idiomatic reasons.

But please have a look at http://caolan.github.io/async/v3/docs.html#controlflow

Forever, queue, series, times, retry, until, waterfall, whilst, etc etc... these are patterns that can all be achieved with promises too but I am sure most devs will do a google search before they do. In fact; some patterns are better served by a library.

Only just yesterday I added https://www.npmjs.com/package/p-limit to get concurrent promise limitation behaviour; one of the many features of that async-lib as well.

Don't misinterpret this as me suggesting these features should be added to the standard; far from it. Community libs do this job quite well.

I moved on from async, I moved on from Promises and embraced async/await.

Do I like it? No, I much rather use Golang's channels. But async/await is idiomatic and plenty of libs out there to handle complex use cases.

Almost everyone has moved on, and anyone writing promises at this moment is just creating legacy for anyone who is going to maintain it. Is that a good reason in itself? No, but it is a very valid one, that is my point.

Re: I Avoid Async/Await

#127

Post by andix » Sat, Apr 16, 2022, 3:30 PM UTC

I always do

  await Promise.all(…)

And now?

Re: I Avoid Async/Await

#128

Post by savanaly » Sat, Apr 16, 2022, 3:32 PM UTC

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.

This is absolutely correct why is it being downvoted lol

Re: I Avoid Async/Await

#129

Post by mpweiher » Sat, Apr 16, 2022, 3:37 PM UTC

gombosg wrote: post #10

As a fullstack dev, I worked with - Spring MVC (Java Futures) - Spring Webflux (Reactor observables) - Scala (Scala Futures & for comprehensions) - TS async/await - Angular observables - React hooks (which combined with Redux, React Query etc. is a special approach to async programming.) I think it's very important to understand that ultimately, async (non-blocking) programming is kind of a "hard problem" and there i…

> I don't agree with the author that we shouldn't use async/await because it _looks like_ synchronous code.

Not having code that is actively deceptive sounds like a good idea to me, so agree with the author.

> We _should_ use it to keep syntax simple and clean wherever possible!

Having clean and simple syntax for async operations is a laudable goal.

Having code that is actively deceptive about its semantics seems less than ideal for accomplishing this goal.

Maybe we need to figure out new and different syntactic constructs that are clean and simple, but do not pretend to be something they are not?

Re: I Avoid Async/Await

#130

Post by oauea » Sat, Apr 16, 2022, 3:37 PM UTC

love2read wrote: post #113

bin_bash wrote: post #89

Earlier quoted context omitted.

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

this works in older versions of node too: const wait = require(‘util’).promisify(setTimeout)

but not in the browser