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

131–140 of 242 posts

Re: I Avoid Async/Await

#131

Post by wiml »

eurasiantiger wrote: post #124
RobertWHurst wrote: post #122

Earlier quoted context omitted.

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.

Well, they're junior devs. You're supposed to help them get past that stage, not just throw away all your tools.

Re: I Avoid Async/Await

#132

Post by joe_guy »

eurasiantiger wrote: post #124
RobertWHurst wrote: post #122

Earlier quoted context omitted.

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.

I'm going out on a limb here and assuming the issues with their code don't begin and end with async.

Re: I Avoid Async/Await

#133

Post by joe_guy »

bin_bash wrote: post #89
Aeolun wrote: post #86

Earlier quoted context omitted.

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

There's no merit of what should be a project wide function being a single line instead of 3 to avoid "hard to grok" syntax.

Re: I Avoid Async/Await

#134

Post by darepublic »

This take is garbage imo. Coming from someone who first used jquery deferred, then native promises and now async await. If you are too inexperienced to use await properly no reason to think callback hell is going to make it better

Re: I Avoid Async/Await

#135

Post by wonnage »

gorjusborg wrote: post #106
jrwr wrote: post #57

Earlier quoted context omitted.

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.

Threads are their own steep learning curve, I think it's just hard to do two things at once.

Re: I Avoid Async/Await

#136

Post by wonnage »

mpweiher wrote: post #129
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 les…

How are they deceptive? I don't know where the idea that these keywords somehow mimic synchronous code comes from.

Re: I Avoid Async/Await

#137

Post by cercatrova »

eurasiantiger wrote: post #124
RobertWHurst wrote: post #122

Earlier quoted context omitted.

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.

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

> usually junior front-end

So you agree with each other then?

Re: I Avoid Async/Await

#138

Post by omgbear »

For me, the key to async/await is a linter that complains about un-handled promises. I appreciate in Go that any green threads are created explicitly with `go`, whereas in typescript, they are signaled by the return type.

My most recent background was in Go and so my mental model now is that async functions are similar to goroutines and `await` is a nice result collection mechanism.

What's recently confused me is that exceptions from yet-to-be-awaited promises crash if you await anything else first.

Re: I Avoid Async/Await

#139

Post by hn_throwaway_99 »

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 mean, I know its a bit of linguistic flourish, but considering NodeJS was only initially released 12 years ago, that's quite a feat!

Re: I Avoid Async/Await

#140

Post by mpweiher »

wonnage wrote: post #136
mpweiher wrote: post #129

Earlier quoted context omitted.

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

How are they deceptive? I don't know where the idea that these keywords somehow mimic synchronous code comes from.

It's not the keywords that are deceptive. It's keeping the rest of the code in a structure that is extremely different from what actually happens.

https://dl.acm.org/doi/10.1145/3297280.3297528

"To solve JavaScript's callback hell problem, several language mechanisms like Promise and async/await have already been introduced to JavaScript. Using async/await, which is the most promising one, callback hell code can be rewritten to another simple and shallow nested code with (almost) the same behavior. Unfortunately, however, it is still difficult to precisely understand the execution order of the rewritten async/await code, because the semantics of async/await is difficult.

This paper first clarifies that this problem is caused by the difficulty of the async/await semantics. Then, we propose and implement a novel async/await visualizer called AwaitViz, to support for programmers to understand the execution order of async/await. Our contribution is twofold. First, we show the feasibility of implementing the visualizer AwaitViz based on source-code instrumentation, which provides precise information on the JavaScript's asynchronous behavior. Second, we show the difficulties and limitations of implementing AwaitViz."

Post reply on HN