I Avoid Async/Await • Hacker News Board

Re: I Avoid Async/Await

#141

Post by frankincense » Sat, Apr 16, 2022, 3:59 PM UTC

jokethrowaway wrote: post #9

Async / await is nice syntactic sugar. I don't understand why they copied the naming from c# over do syntax in Haskell (which dates roughly 1995, if I'm not mistaken). The main problem is error handling, having to use try / catch is pure cancer and really screw up your closure. You can use catch together with await / async but then you're not dealing with exceptions outside the promises.

Typescript and C# are both developed and maintained by Microsoft, and the lead architect of C# is also the creator of Typescript. (Both great languages, IMO)

Re: I Avoid Async/Await

#142

Post by kabes » Sat, Apr 16, 2022, 4:05 PM UTC

eurasiantiger wrote: post #32

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…

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

I agree but second one could just be `() => Promise.resolve()`

Re: I Avoid Async/Await

#143

Post by bsuvc » Sat, Apr 16, 2022, 4:05 PM UTC

> I Avoid Async/Await

Tell me you're a difficult teammate without saying you're a difficult teammate.

Re: I Avoid Async/Await

#144

Post by rootusrootus » Sat, Apr 16, 2022, 4:07 PM UTC

Even though I feel competent enough using them, I continue to dislike promises in any form, no matter how much syntactic sugar there is.

Re: I Avoid Async/Await

#145

Post by Izkata » Sat, Apr 16, 2022, 4:08 PM UTC

AshleysBrain wrote: post #93

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.

A rejected promise is passed along until it hits a catch. Both save calls are handled by the one there.

Re: I Avoid Async/Await

#146

Post by Cpoll » Sat, Apr 16, 2022, 4:13 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(…);

> function getData() { return fetch(…); }

I feel like there are advantages to making it `async function`, even if it's superfluous, because it signals to readers and to static code analysis that the function returns a promise. That's assuming the return type of fetch(...) can't be inferred by static analysis and developer tooling.

Re: I Avoid Async/Await

#147

Post by PaulDavisThe1st » Sat, Apr 16, 2022, 4:14 PM UTC

wonnage wrote: post #135

gorjusborg wrote: post #106

Earlier quoted context omitted.

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.

It's easy to do two things at once when you can ask two different entities to do them for you (threads).

What's hard is thinking about how to coordinate the work they are doing for you: when to consider them done, how to ask them if they did the work successfully, what to do if they need to use the same tool at some point during the work etc.

Re: I Avoid Async/Await

#148

Post by lmc » Sat, Apr 16, 2022, 4:14 PM UTC

michaelsalim wrote: post #67

dataflow wrote: post #63

Earlier quoted context omitted.

new Promise() is not how you want to create a promise in JS (except when you really have to), just like 'new'/'delete' are not how you ant to allocate memory in C++ (except when you really have to). There are lots of helpers in that class that make promises significantly more ergonomic.

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

Here's a few. The docs link to some others that may also be useful...

Promise.resolve()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You can use this in place of new Promise() (though you rarely need it, as an async function automatically wraps any non-promise return value in a promise.)

----------

Promise.all()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

For making requests in parallel, and returning when all have been successful.

----------

Promise.allSettled()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

For making requests in parallel, and returning when all have completed whether successful or not.

----------

Promise.any()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

For making requests in parallel, and returning the first successful response.

--------

As mentioned in sibling comment, things like fetch and DB calls return promises anyway, so the above are mostly only useful for working with multiple other promises.

Re: I Avoid Async/Await

#149

Post by garyrob » Sat, Apr 16, 2022, 4:19 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'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?

Re: I Avoid Async/Await

#150

Post by saimiam » Sat, Apr 16, 2022, 4:22 PM UTC

RedShift1 wrote: post #70

saimiam wrote: post #68

Earlier quoted context omitted.

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.

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?

I think you’re trying to recreate the semantics of Promise.all without using Promise.all.

You’re effectively saying that Promises are a better async programming paradigm than async/await…which is also what the author is saying in the article.