Live data from Hacker News

I Avoid Async/Await

uniqname.medium.com

61–70 of 242 posts

Re: I Avoid Async/Await

#61

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 prefer async/await but this is a contrived example.

For starters you can just write:

    const myfunc = () => new Promise(resolve => resolve())
or

    Promise.resolve()

Re: I Avoid Async/Await

#62

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.

async/await is not the same as the do-notation, that's why.

How is it not?

Re: I Avoid Async/Await

#63

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() ) }

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.

Re: I Avoid Async/Await

#64

Promises are the most awful programming syntax I have ever come across. Await is sweet release from death as nowadays almost all apis are forced onto promises. Thank god xhr and websockets came before promises were mainstream, but for example webserial is absolutely horrible to use. Function callbacks are the best, though I wish JS would support function scheduling.

Who actually thinks like this?

Callbacks were absolutely unmaintainable. Promises (and `async/await`) are really not that hard.

Re: I Avoid Async/Await

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

Agreed, I stopped reading after this sentence.

Re: I Avoid Async/Await

#66
We need an AI to design a language that is optimal for humans to program with. Languages should be designed by behavioral scientists rather that computer scientists bcause their goal is to adapt to the human rather than the machine. For example one of the biggest limitations of humans is limited capacity of working memory. Async paradigms exhaust this limit very early and lead to frustration compared to serial programming. Writing one of them in the form of the other doesn't solve any problem and is indeed a travesty

Re: I Avoid Async/Await

#67

Earlier quoted context omitted.

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

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

Re: I Avoid Async/Await

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

Re: I Avoid Async/Await

#69
post #57
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.

Hyperscript can help with this. https://hyperscript.org/

Makes using a bit of JavaScript relatively simple, just not much in Stack Exchange yet which means reading docs..

Re: I Avoid Async/Await

#70
post #68
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.

  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?
Post reply on HN