Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async/Await will make code simpler

blog.patricktriest.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: Async/Await will make code simpler

#61

Post by tracker1 »

dlbucci wrote: post #22

I was super excited about async/await when it first came out. I hadn't really understood the point of Promises, but async/await looked simple and useful. However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere. Code using async/await seems to be more verbose and unruly than just sticking to Promises, which I now appreciate the elegance of much more (call…

If you're awaiting/catching upstream, you don't need to wrap at the lower level, and it can be cleaner.

    const delay = ms => new Promise(r => setTimeout(r, ms));

    async function fooErrors() {
      await delay(100);
      throw new Error('I failed');
    }

    async function doSomething() {
      await fooErrors();
    }

    async function main() {
      try {
        await doSomething();
      } catch(err) {
        log.fatal(err);
      }
    }

Re: Async/Await will make code simpler

#62

Post by tracker1 »

tarr11 wrote: post #4

Though the article doesn't mention it, the "alternative" is Reactive programming (via RxJS) I think for the typical UI application developer, async / await can provide easier readability and debugging, but at the cost of some expressive power and conciseness. Now that chrome supports async / await in the debugger, it's almost certainly the best choice, compared to promises and callbacks. In the redux world, you can s…

I think it's worth noting that async/await is a bunch of sugar around promises... All async functions return a Promise... and all awaits await on a result or promise resolution. and Errors will bubble out.

This is helpful as many times I'll write a function that simply returns a promise to wrap around an older callback style function. I know I can promisify, but this doesn't always work as sometimes the methods need their context.

As to redux, frankly, I find redux-thunks + async functions to work pretty well together until you need more.

Re: Async/Await will make code simpler

#63

Post by tracker1 »

hitgeek wrote: post #3

same example with async control flow library and node style callback conventions function getUserInfo(callback) { async.parallel([api.getUser, api.getFriends, api.getPhoto], callback) }

    function getUserInfo(cb) {
      Promise.all([
        api.getUser(),
        api.getFriends(),
        api.getPhoto(),
      ]).then(
        ([user, friends, photo]) => 
          cb(null, {user, friends, photo}),
        cb,
      );
    }

Re: Async/Await will make code simpler

#64

Post by hitgeek »

tracker1 wrote: post #63
hitgeek wrote: post #3

same example with async control flow library and node style callback conventions function getUserInfo(callback) { async.parallel([api.getUser, api.getFriends, api.getPhoto], callback) }

function getUserInfo(cb) { Promise.all([ api.getUser(), api.getFriends(), api.getPhoto(), ]).then( ([user, friends, photo]) => cb(null, {user, friends, photo}), cb, ); }

I do this with so many libraries now. especially in the react-native ecosystem.

I just prefer node style callbacks, so I wrap libraries with promise based APIs with callback based wrappers.

hopefully i'm not the only one.

Re: Async/Await will make code simpler

#65

Post by jcelerier »

throwasehasdwi wrote: post #46
jcelerier wrote: post #32

Earlier quoted context omitted.

> that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance. programs aren't just pure computations. There are plenty of times when you want a specific event to happen at a specific time (as in, wall-clock), and plenty of times when you don't care when something computes as long as you end up getting a result at some point.

You don't get reliable wall clock time unless you're working in RTOS. In a threaded OS everything in userland is async to an extent. In this school of thought, having to specify that something should be async manually could be seen as a failure of the language.

on recent good hardware there is no problem being around 1ms accuracy.

Re: Async/Await will make code simpler

#66

Post by davnicwil »

thinbeige wrote: post #57
davnicwil wrote: post #12

I heard Doug Crockford talk about how he doesn't think async/await is that great an idea on a podcast a while ago. His argument was that it's an unclean abstraction - it gives you access to 'features' of synchronous imperative syntax (lines in a function always execute in order, try-catch blocks, etc) but it remains conceptually and literally promises all the way down. Therefore, all await 'calls' are really non-bloc…

> honestly it is often to the detriment of understanding it when you come back to that code it in a few weeks. Not in my case. I think async await makes everything quite clear BUT you have to understand promises and async await well. This stuff ia super tough and I needed a week or more. Then you can produce quite elegant code.

Maybe I didn't get this across but I do understand async/await and promises well, and that's kind of the point - it's still troublesome at times for me to understand at a glance once I'm out of the context of the code.. precisely because it's a slightly unclean abstraction.

Re: Async/Await will make code simpler

#67

Post by krono »

coldtea wrote: post #34
krono wrote: post #11

try catch try catch try catch try catch try catch try catch try catch try catch

Or, you know, a single try catch. Or several of them. At any level you like and fits the problem. And no lost exceptions.

You're right and async await is much nicer but all the try catch blocks are slowly getting to me

Re: Async/Await will make code simpler

#68

Post by rounce »

jrs95 wrote: post #9
tarr11 wrote: post #4

Though the article doesn't mention it, the "alternative" is Reactive programming (via RxJS) I think for the typical UI application developer, async / await can provide easier readability and debugging, but at the cost of some expressive power and conciseness. Now that chrome supports async / await in the debugger, it's almost certainly the best choice, compared to promises and callbacks. In the redux world, you can s…

Only downside I've found with this is that Observables feel like more of a pain to test, since your logic gets more tightly coupled to your I/O. Or at least there's more complexity involved in the relationship between I/O and data manipulation. I used them for a Node project via RxJS and ended up just switching back to promises, as it wasn't complex enough of a project to really see much of a benefit from Observables…

The only difference between promises and observables are multiple-emission & cancelation, they shouldn't be any more complicated to use or test than promises. Often I find the main complicated part is the source, everything else is just filter/map functions, sometimes to more streams. All of these individual units are more easily described/tested in comparison to the entire chain (and even then you are only caring about the ends of it).

Re: Async/Await will make code simpler

#69

Post by davnicwil »

lexicality wrote: post #19
davnicwil wrote: post #12

I heard Doug Crockford talk about how he doesn't think async/await is that great an idea on a podcast a while ago. His argument was that it's an unclean abstraction - it gives you access to 'features' of synchronous imperative syntax (lines in a function always execute in order, try-catch blocks, etc) but it remains conceptually and literally promises all the way down. Therefore, all await 'calls' are really non-bloc…

> I've made plenty of stupid mistakes where the two 'faces' of the abstraction don't marry up, and it's frustrating. Would you mind sharing any of these?

I'm talking really stupid, small, frustrating things, mostly at the interfaces. I read a return x at the bottom of one function and call the function elsewhere and try to use x, but oh wait no.. it was an async function so I've really got Promise.

Generally it's just because of the leaky abstraction making very fast mental mapping of code a bit harder.

Post reply on HN