Async/Await will make code simpler

https://blog.patricktriest.com/what-is-async-await-why-should-you-care/

by thmslee • 9 years ago

107 92 9 years ago

blog.patricktriest.com

mpweiher2• 9 years ago

I go back and forth on async/await. On the one hand, it is utterly brilliant. On the other hand, it seems like the final epicycle, trying to fit a theory of circular geocentric orbits (call/return) onto a real world of elliptical heliocentric ones (asynchronous programming).

So yes, it will make code easier, but I fear that will only serve to prolong the dominance of what is arguably the wrong programming model/architectural style. Or more precisely: an insufficient programming model/architectural style (it is great for a lot of things, just not for all).

throwasehasdwi2• 9 years ago

await/promises/etc mostly exist to solve the problem that JavaScript doesn't have threads so it can't wait for callbacks.

About JavaScript, many other languages have had async/await for a long time. I have no idea why JS made such a huge deal of promises, I guess they're better than the callback hell before. Of course, in most languages using async isn't nearly as important for performance because they have thread pools.

Some interfaces aren't and won't be asynchronous (like Linux file IO) so eventually JS will support proper threads and we can stop talking about how great asynchronous programming is (it isn't).

jrs952• 9 years ago

Node has threads in C++ for that sort of thing. Async programming is a big deal for performance. That's essentially the main reason Node is any faster than Python. If you use fully async Python on uvloop, you can get comparable performance.

jdmichal• 9 years ago

Maybe promises come before async/await, in an evolutionary sense. Same way that for-each loops seem to precede generators / yield. C# added Task before the syntax sugar of async/await. Java currently has Future, and I expect async/await to finally show up in about 10 years time...

iainmerrick• 9 years ago

await/promises/etc mostly exist to solve the problem that JavaScript doesn't have threads

async/await was popularized in C#, which does have threads.

Rusky• 9 years ago

The way I look at it is as just another way of manipulating continuations, alongside conditional, loops, call/return, generators, coroutines, exceptions, etc. Even in some other hypothetical asynchronous paradigm, all those patterns still occur all over the place, so making them all composable with each other is a win. (Credit to http://blog.paralleluniverse.co/2015/08/07/scoped-continuati... for describing it this way.)

The surface syntax could maybe use some work- maybe make functions generic across asynchronicity, maybe swap `await` to being the default and explicitly mark the case where you want a reified Promise instead, etc. But in the end it's another valuable control structure.

coldtea3• 9 years ago

So yes, it will make code easier, but I fear that will only serve to prolong the dominance of what is arguably the wrong programming model/architectural style.

Nested callbacks and even Promises are not the "right model/style" by any measure. Even 30+ year old languages had better answers to asynchronous programming than that.

Nested callbacks is so backwards its like writing in assembly. Only people whose first exposure to asynchronous programming was Node think it's a valid programming style.

jMyles2• 9 years ago

Nested callbacks is so backwards its like writing in assembly. Only people whose first exposure to asynchronous programming was Node think it's a valid programming style.

It depends on precisely what structures you include in your definition of "nested callbacks" here. I think that the callback and errback chains on the Deferred object in Twisted is basically the perfect abstraction for the flow control they represent.

mpweiher2• 9 years ago

Nested callbacks and even Promises are not the "right model/style" by any measure.

Of course not.

hitgeek2• 9 years ago

same example with async control flow library and node style callback conventions

function getUserInfo(callback) { async.parallel([api.getUser, api.getFriends, api.getPhoto], callback) }

askmike• 9 years ago

Even with a library like async there will be so much boilerplate, since you need to handle (or pass) errors every step of the way.

With async/await you only need to deal with errors at the level you actually care about them (using the language build in try/catch block).

yesbabyyes• 9 years ago

In the example above, any error will be passed to the callback sent to getUserInfo - i.e., where you care about it.

samblr• 9 years ago

Agreed there there is boiler plate - but with use of live templates in webstorm (or snippet in VS) - I find it getting easier.

tracker13• 9 years ago

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

hitgeek2• 9 years ago

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.

tarr11• 9 years ago

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 see this by comparing redux-observable [1] (reactive / rxjs) with redux-saga [2] (generators)

Rxjs requires a deeper understanding of Reactive programming. Once you understand it, you can write very powerful expressions in a few lines. But debugging is tough and it doesn't translate well for your fellow developers.

[1] https://github.com/redux-observable/redux-observable

[2] https://github.com/redux-saga/redux-saga

jrs952• 9 years ago

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.

alexkoeh• 9 years ago

Along with that, generators (redux-saga) are amazingly simple to test.

rounce• 9 years ago

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

tracker13• 9 years ago

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.

imperio59• 9 years ago

Anyone else bothered by the utter lack of semicolons in the example code? :D

kjsthree• 9 years ago

Let go and let god. :D

strictnein• 9 years ago

Yes It's like reading English without periods It's frustrating

askAwayMan• 9 years ago

If you've got a halfway decent linter, semicolons are just clutter. https://eslint.org/docs/rules/no-unexpected-multiline is the sort of thing that makes semicolon free style practical.

Bahamut• 9 years ago

There is one situation where semicolons are important - when concatenating multiple script files & using IIFEs.

This subtlety is being obsoleted by ES modules & the build tooling around them, but it is a nasty bug that has sucked many an hour away from frontend devs whenever it is encountered.

krono2• 9 years ago

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

marcofatica• 9 years ago

better than then().catch().then().catch().then().catch().then().catch()

coldtea3• 9 years ago

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

krono2• 9 years ago

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

davnicwil3• 9 years ago

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-blocking at a global level, yet they appear blocking to the local lines of code inside the same async function. This is liable to cause confusion - particularly for beginners or occasional visitors to JS who don't fully grok or have the concept of promises top of mind - but really for everyone.

I've used async/await a fair amount in production code now (with babel) and while it does make some code a bit cleaner, honestly it is often to the detriment of understanding it when you come back to that code it in a few weeks. I've made plenty of stupid mistakes where the two 'faces' of the abstraction don't marry up, and it's frustrating.

More and more I'm inclined to just use promises, even when I have the choice of async/await - call a spade a spade and get on with your day. The article talks about promise chains getting complex and hard to read. Well, if this is the case, maybe it's your code or logic flows in general that need to be cleaned up, and changing the syntax to flatten the structures is actually just a sticky plaster over that.

lexicality• 9 years ago

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?

davnicwil3• 9 years ago

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

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

wahern3• 9 years ago

Here's a great article somebody posted on HN awhile back, "What Color is Your Function?"

-- http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

The proper abstraction is threads--i.e. a stack structure used for the storage of temporary values, which is shared by nested function invocations as well as similar structured programming constructs like if/else conditionals that together represent a singular thread of control through the program as it processes data and events. "Thread of control" is precisely what you're cobbling together with promises, async/await, etc, using clunky compiler constructs bolted onto the language model and implementation. The problem is that we conflate the implementation with the abstraction, sometimes by necessity (the legacy of the contiguous, so-called "C stack") but usually unnecessarily.

It pays to remember that some operating systems, such as some of IBM's mainframe platforms, IIRC, implement a thread stack as a linked-list of invocation frames, rather than a contiguous array. But it's completely transparent, as it should be. Async/await does the exact same thing, except it's not transparent as it should be. So now you have _two_ distinct, mutually incompatible kinds of functions solely because the implementation is unable to properly hide the gory details, which is ludicrous on its face.

aidenn03• 9 years ago

light-weight multithreading that enters a scheduler loop when I/O would block is great, and I haven't seen any advantages of async/await compared to that, other than ease of implementation (you make the programmer or library author implement multithreading, rather than implementing it in your runtime).

Promises are at least slightly more interesting because they can functionally compose in various ways (but most of the time it's just a dozen then() calls in a row, and threading would have been better).

jd20• 9 years ago

I feel the conclusions of that article were pretty spot on. Having done a bunch of async programming in Go, and now picking up Node on the side, I can't help but agree that Go got this right. You have the simplest conceptual model (a synchronous one), with the runtime responsible for making it all run async. JS certainly seems to have come a long way, but it feels like the next step will be the most difficult one, requiring a serious redesign of the runtime itself.

zzzcpan3• 9 years ago

You have two distinct function calls to know exactly which one is giving up control and which one doesn't. This allows for synchronization-free programming model.

And even if your green threads implementation multiplexes them onto a single thread where technically you don't have to do synchronization, having identical function calls makes it very hard to guarantee where your code yields and you still have to use synchronization primitives with all the problems that come with it.

thinbeige• 9 years ago

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.

davnicwil3• 9 years ago

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.

BoorishBears• 9 years ago

It's funny watch Js go through the motions C# did with TPL and Async/await.

The same exact arguments and pitfalls coming up

billytetrud• 9 years ago

I use the futures from node-fibers all over the place in my backend code. It has possibly only once caused me confusion over something. If you're writing your code right, it shouldn't cause confusion. You don't need to make your code ugly to understand when things are asynchronous.

dlbucci• 9 years ago

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 (callee convenience/error delegation).

I think I'm just going to stick to Promises for the time being, until I see some hidden usefulness of async/await syntax (which could totally happen. It took me a long time to realize how awesome promises are).

zackify• 9 years ago

You can abstract your try / catch logic to a higher level to fix this easily. make all promises extend from a base promise function that either returns a result, or null (or an error, you can make it more complex). Then,

    let data = await customPromise()
    if(!data) return

this would be better in my opinion that try catch everywhere. Inside that higher order promise you can catch and handle errors.

jMyles2• 9 years ago

This sounds confounding to me as a reader - you're telling me that exceptions will intentionally be handled further from where they're raised?

pier25• 9 years ago

I'd rather user try/catch than endless chains of then().

sharemywin• 9 years ago

andThen()...andThen()...andThen().andThen().andThen();

koolba• 9 years ago

However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere.

Why do you have try/catch everywhere? Unless you're actually going to handle the error, you shouldn't do anything as it will bubble up till it gets to a piece of the app that can handle it. For web apps a lot of the time that's a single request level handler to return a 5XX.

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 (callee convenience/error delegation).

Eh? Besides the addition of the "async" keyword on the top level function, it's always less verbose.

Where I think things get a bit tricky is awaiting the composition of Promises to support parallel processing (as opposed to just 1) await foo() 2) await bar() ...). It's best to treat that like regular composition and simply await the result.

treve• 9 years ago

This makes little sense. You don't need more try..catch blocks than you would normally have a catch promise clause.

Exceptions bubble up.

duncanawoods2• 9 years ago

I'm finding that with client side async, the awaited behaviour is often external, heterogeneous and unreliable. When an operation fails, it typically requires a state-machine transition to a failed/retry state or fallback service rather than just bubbling up to a top level handler like a coding error i.e. there is something specific you need to do unlike typical exceptions.

Retrofitting a code base with async I concur that local try / catch has been necessary and has added code complexity and doesn't always feel like an improvement. In contrast, server side async has been much more elegant because the errors with internal async server operations are much more exceptional and don't require so much case specific handling.

raquo2• 9 years ago

hmm were you previously using Promise.catch for flow control? It's basically as bad as using exceptions for flow control, just with with a different set of bubbling / propagation problems. Unless you're dealing with truly exceptional conditions you should not be throwing inside your promises, thus no need for try / catch when converting them to async/await.

lobster_johnson• 9 years ago

Rejection is turned into an exception with "await", though. And rejection is perfectly normal with, say, network I/O.

tracker13• 9 years ago

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

yarg3• 9 years ago

I really don't see the need for such a syntax. If I say:

  Foo foo = someFoo();
  ...
  String content = foo.getContent();

I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined.

There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated.

The biggest problem I see is a when you use this functionality in a loop of independent executions (when the results of any given loop don't depend on the results of prior loops):

  for(Foo foo: asyncFoos()){
      Foo foo = someFoo();
      ...
      result.add(foo.getId(), foo.getContent());
  }

The problem here is that the use of a for loop will introduce latency, potentially dramatically increasing execution time.

Now you can either replace this "for" with some sort of "for-each" type of block, or you can go async all the way and treat "for" as "for-each" and any referenced result of a prior iteration as yet another async value.

That covers sets and singletons, I imagine that any other situation that needs to be dealt with can also be covered on the compiler side of things with only minimal changes to syntax.

whipoodle2• 9 years ago

You may not care, but the computer does!

miguelrochefort2• 9 years ago

Why doesn't the computer do it for me?

yarg3• 9 years ago

Perhaps it does, but my point was it does not need to. The only thing that needs to be ensured is that calls to the object are not issued before the result is returned and assigned - for all code that occurs between the call to get the object and the first actual access of the object, it does not matter.

sim0n• 9 years ago

I personally think that the syntax is great considering it's being added to an existing language. await/async allows you to opt-in to having your code behave in a synchronous-like manner, when you want it to.

One of the best things about JS/Node is that you can wait on I/O from different sources at the same time and since the async/await syntax is just sugar over Promises, you can do things like:

  const [user, notifications, messages] = await Promise.all([
    getUser(),
    getNotifications(),
    getMessages(),
  ]);

Instead of having to wait on I/O sequentially like:

  const user = getUser();
  const notifications = getNotifications();
  const messages = getMessages();

if awaiting were implicit.

yarg3• 9 years ago

It's usable, it's powerful and it's not overly verbose - but I'd contend it's adequate rather than great.

fergie• 9 years ago

Not a gigantic fan of async/await for the reasons that others have mentioned here, but that said it provides the only sane out-of-the-box way for JS to handle loops that contain callbacks/promises.

miguelrochefort2• 9 years ago

I much prefer observables to tasks...

jaequery• 9 years ago

not too long ago, async used to be the "thing".

and now sync is the new "hot stuff".

a bit ironic but at the end of the day, simplicity always wins.

stevedekorte• 9 years ago

Async/await can be used to implement coroutines, but IIRC only if you wrap all of the code that might be called in async/await as well, and this catch makes them practically useless. Why not just provide proper coroutines?

hdhzy2• 9 years ago

Because people don't need coroutines, just a simpler way to write async code than callbacks and manual promises.

While we're at it why coroutines? You can implement coroutines, generators, even try/catch and return given continuations [0].

[0] https://curiosity-driven.org/continuations

atombender• 9 years ago

I wish the await syntax was inverted; instead of waiting for an async function, let all async functions await by default. In other words, I wish this worked:

    let foo = myAsyncFunc()
    foo.bar()

Why? Because that's the common case, and the caller shouldn't care whether the function is async or not. If you have a non-async function that you want to change to be async, or the other way around, then you have to change every single call site.

The case where you want to store a promise or wait on multiple is actually the edge case, and they could have reused "async" here:

    Promise.all([
      async myAsyncFunc(),
      async someOtherAsyncFunc()
    ]);

Bonus functionality: If you do "async foo()" and foo() isn't async, the compiler could still ensure that it provided a promise.

Sadly, it's too late for this, and everyone's code will suffer as a result. It's way too easy to forget to add "await" to an async call, and doing so leads to failures that can be hard to track down.

mo_po• 9 years ago

JavaScript often feels too verbose. That's why I like to use elm whenever it is possible.

singularity2001• 9 years ago

I wish your comment gets upvoted to national news. Those async antipatterns are worse than the 'goto' statement. Time for programming languages to add the 'async' keyword on the caller side.

chronial• 9 years ago

If you have a non-async function that you want to change to be async, or the other way around, then you have to change every single call site.

At least in the direction non-async -> async, that is clearly a good thing, since you are changing semantics a lot.

This code is always safe:

    x = globalObject.a
    functionWithoutSideEffects()
    gobalObject.a = x + 1

While this is not:

    x = globalObject.a
    await functionWithoutSideEffects()
    gobalObject.a = x + 1

> It's way too easy to forget to add "await" to an async call, and doing so leads to failures that can be hard to track down.

This a situation that could clearly be improved with better detection of these cases. Or maybe it should be completely illegal to call an async function without a keyword, so you have to do either `await func()` or `promise func()`.

mvindahl• 9 years ago

I really like the succinctness of async/await, and I feel like it's the last step of a long journey. The single threaded callback based style of Javascript has always been a mixed blessing. It has allowed for great performance, and it gives better control that having to juggle threads, but it was all to easy to get into deeply nested callback hell.

If you see design patterns as indicators of language smells -- and it's a useful perspective IMHO -- then in this case callbacks were the smell and the various promise libraries were the design patterns. It's a nice thing that promises and their async/await sugercoating have fairly rapidly made it into the core language.

Now, for the one thing that I don't like about async/await: it's deceivingly simple and it's bound to fool both novice programmers and programmers arriving from threaded languages. If you don't understand the underlying concept of promises, you'll easily end up writing suboptimal code (e.g. executing stuff in sequence which would be better executed in parallel).

Still, a net win.

Async/Await will make code simpler

Related Stories