Hacker News Reader

Comment by postalrat | Hacker News Reader

  (async () => { set(await get()); })();
 
  get().then(r => set(r));

Ignoring error handling I'll often choose the second option.

View on HN

Much cleaner. You can go even further by using point-free style:

    get().then(set)

It's the try/catch blocks that make async/await truly worse than native promises. I use them sparingly because so often the .then syntax is both clearer and terser.

What don't you like about try/catch? I find the opposite true, the .then/.catch is more confusing.

try/catch introduces new block scopes and interrupt control flow. I find this example very readable, but expanding it into try/catches would make it rather long winded and harder to see the pattern at work as you extend the sequence:

    get()
        .then(handleResult)
        .catch(useFallbackResult)
        .then(updateState)

I prefer concision and functional expressiveness because it reduces the surface area for writing buggy code. Much like how using map instead writing a for loop can eliminate out of range index bugs, chaining promises brings useful guarantees about how the code I do write can be interpreted.

OK. I'll do:

  const result = await get()
  set(result)

But you do you.

Current node and console have top level await BTW.

That only works in an async function. The then example doesn't have that requirement. So the alternative shouldn't either.

Yes, your example isn't complaining about then() being clearer than await (because it isn't) but rather complaining that top level await isn't everywhere yet.

In other words, your complaints have disappeared in node, and will soon in browsers: https://github.com/tc39/proposal-top-level-await

So yes:

    set(await get())

Sometimes you may need to handle a promise in a function that can't be made async.

If a function is inherently sync, then it shouldn't be using promises.

Reply on news.ycombinator.com