let foo = myAsyncFunc()
    foo.bar()

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

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.

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

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

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

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.

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

It's not uncommon to use a select statement to allow work to continue (it may act like a loop) and wait to receive a message on a channel. This is the common pattern for handling timeouts: create a timer goroutine that will wake at a set time and send a message to a timeout channel, keep checking to see if work is done, and if the timer fires then cancel the select with an appropriate message (function call or return an error value).

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.

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

FWIW, I'd be careful about conflating issues such as how to handle I/O. Threads don't imply preemptive scheduling. Lua coroutines are implemented as threads, but that's the extent of things--there's no builtin scheduler or event loop nor features specifically directed toward implementing those things[1], just coroutine.resume and coroutine.yield. (yield can be called from any function at any depth as long as the call stack is on a coroutine thread, which in Lua is every stack except the main one.) And that's fine by me. The most fundamental issue from the perspective of the language design is about how to represent a thread of control that is consistent with the other structured programming constructs like function calls. A batteries-included event loop or a preemptive scheduler are nice to have, but notably they're much easier to implement (internally or third-party) and use if you have a thread construct.

[1] Debugging hooks notwithstanding.

That's my point. The better _abstraction_ for all these things is a thread, no matter how you choose to schedule chunks of work or how you choose to implement things under the hood. A thread is just a construct that encompasses nested function invocations, and that construct is what promises and async/away emulate, except that that they leak implementation details and restrict the normal things functions do, like call other functions.

Though I must admit I've not done cooperative multitasking in a language with operator overloading so I can't say whether or not this is a problem in practice.

Would you mind sharing any of these?

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

The same exact arguments and pitfalls coming up

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.

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

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.

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

Exceptions bubble up.

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.

Exceptions work best when the error is fatal for the local scope but responses from external services aren't like that. The general problem is that the dividing line between errors and information becomes too blurry - your error might only be information to me. A simple example is where something like axios will (by default) throw on 404 responses but an external api might use 404 to indicate a resource does not exist. If your app logic makes a decision based on this information, you will find yourself using exception handlers for control flow despite not experiencing any actual errors.

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

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

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.

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

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.

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

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

This blog posts elaborates on that better then I could do here, so I'm just going to link to it: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

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.

Edit: as other poster mentioned, async/await and promises also don't help with precise wall-clock time but that is entirely different matter.

v8's JIT is many times faster than Python in CPU bound tasks without any asynchronicity involved.

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.

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.

Of course not.

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

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

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.

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(),
  ]);

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

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.

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

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

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

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.

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

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.

and now sync is the new "hot stuff".

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