Hacker News Reader

Comment by aboodman | Hacker News Reader

Biggest advance in JavaScript since ... I don't even know. XHR? Reasonable GC performance?

I've intentionally been keeping myself ignorant about async/await in JS until it's common enough I can consider using it natively without any great concern about cross browser compatibility. Why is everyone so excited for it? From the example it looks like a thin syntactic sugar layer over normal promises, what's so great about saving one level of indentation?

Ability to use asynchronous functions without pulling everything depending on them into a closure, which comes with a lot of baggage in how you have to structure things.

Honest question, does async/await not create some variety of an implicit closure?

It's explicit, since the `async` keyword must only precede a function declaration.

i.e.:

    async function () { ... }
    
    // or 
    
    async () => { ... }

I believe they are discussing at the call site of an asynchronous function

Depends how you look at it. The straightforward answer would be "no" because await lets you assign the result of a promise to a variable without calling `.then(...)` with a callback and then accessing the variable inside the callback (where the callback would be the closure). In that way of thinking, async/await directly let us write code with less closures.

Note that that explanation was purposefully ignoring any implementation details about whether or not closures are actually being created/allocated and was purely focusing on whether the programmer had to type out/read closures as extra syntax.

Actually, functional programmers might point out that even without async/await, assignment in imperative languages is still just some syntactic sugar for actually using closures. That is, in functional languages, its almost never idiomatic to directly "assign" to a variable (that is, overwriting the variable's previous value); instead values are "bound" to variables in let statements (or whatever the language's idiomatic equivalent is)--and let statements are effectively syntactic sugar for function calls/closures.

If you're familiar with haskell: you can think of imperative code as haskell's do notation but with the Identity macro (aka no special mode of computation, just the results of each function flowing into the next with "assignment" converted into functions). Marking a function as async (and thus allowing you use to await inside it) is just switching that function to be under the Promise monad. (but be careful! JavaScript promises aren't strictly monadic in that they auto-resolve if nested... so you can't have "Promise Promise a")

(... Sorry, this ended up being a bit of a mess of a braindump because you specified "implicit" closures :) )

I've used both. In my opinion, promises are fine for simple scenarios, but once you start doing anything complex, the synchronous "feel" of async/await make your code much easier to read and reason about.

It is safe to use it in the server side. Very soon it will be released a Node.js version with the V8 async/await additions included.

NB It's already in Node v7 behind a --harmony flag.

async/await is well designed in that it "converts" into a Promise (and you can await Promises). Even though async code is still "contagious" if you need the result of the computation, sync and async code can now be mixed – the sync code can pass the promises around. This makes it a lot more convenient to use i.e. code is more concise.

Just as a point of interest (maybe), I've been using Redux-Saga on a project it essentially affords the same benefit; it abstracts over any of the JS async primitives (callbacks, promises, generators, etc). It is awesome!

Well, I guess there are three main reasons I'm so excited about async/await:

1. It allows you to reason linearly about code with IO mixed in, without blocking the entire event loop. This is incredibly useful. Computer programmers are very good at reasoning linearly. It is just much, much more comfortable [1] to think about code that uses async/await than the same code with promises.

2. I think the way that promises and async/await interop is very beautifully designed. The way it ends up working in practice is that you can write a function that "blocks"[2], but if you later decide you want to call it in parallel with something else, that's fine because async functions are just a thin wrapper around Promises. So you can just take that existing function and call `Promise.all()` on it. Similarly if you start with a function that returns a promise, and you decide you want to call it in a blocking way -- you just do `await thingThatReturnsPromise()`. This is an almost perfect example of primitives composing to be more than the sum of their parts.

3. (and this is worth the price of admission alone) error handling works properly and automatically. If you `await` an async function and it throws, you'll get a plain ol' JavaScript error thrown which you catch in the normal way. If I never debug another hung JavaScript app that dropped a rejected promise on the floor it will be too soon.

[1] please don't tell me that I just don't "get" asynchronous programming. I was writing js event handlers when you were in diapers (something something lawn something).

[2] `await` doesn't really block the event loop, it just appears to.

> [1] please don't tell me that I just don't "get" asynchronous programming. I was writing js event handlers when you were in diapers (something something lawn something).

This sounds pretentious and detracts from an otherwise good comment, even if you didn’t mean it to.

I read it as more of a whimsical and jokey side comment. I don't think it's that egregious.

Fair enough.

One more thing that's particularly nice about `async/await` is just using the `async` part. For existing functions that should always return promises, when that function is `async` you can be sure of it. Even if it throws. Even if it returns a value that sometimes isn't a promise.

Makes writing correct code easier.

I'm not up to speed on async/await -- do you happen to know if an async function throws on synchronous code (before the first await keyword) -- does that result in an asynchronously rejected promise or a synchronous exception?

It results in a rejected promise. (The other behaviour would be a bit inconsistent/annoying.)

This added contract between the caller and callee is huge. No more searching for that one branch of a non-trivial function that failed to wrap its immediately available return value in a Promise.

The main problem with normal promises is you can no longer use native control structures, because the code before and after the operation has to go into separate functions. Loops no longer look like loops, the bodies of conditionals are less obvious, exception catch points are hidden, etc.

With async/await the language takes care of lowering those control structures that straddle async operations, similarly a compiler lowering them into conditional branch instructions.

If you have a linear chain of async operations (do this, then this, then this, ...) it doesn't change a lot compared to raw promises.

However if you have control flow in it (execute this async function 100 times, add the results, depending on the result call another async function, ...) things will get a lot more ugly with raw promises.

Agreed. Before this and promises it was impossible to reasonable about async scenarios without getting seriously confused.

Allowing programmers to write code as if it was synchronous removes a lot of confusion, boilerplate, and bugs.

> impossible to reasonable about async scenarios

Nothing was impossible. Maybe if you had 3+ levels of nested Ajax calls then it needed bit of head scratching, but jQuery's Deferred and other promise libraries are pretty neat to solve these issues.

However this could be indeed hidden from the programmer.

Using generators can make your code look as if it was synchronous

Removes boilerplate? Yes. Confusion? Sometimes. Bugs? Not really. async/await doesn't inherently change the concurrency model, it is just a different notation for the same thing. Therefore you can still have all the same bugs as with classic promises.

I disagree.

Look, I get its use case. It simplifies doing asynchronous and synchronous programming together. It takes an asynchronous operation and turns it into synchronous which worries me a bit about new developers and code readability. There are APIs including parts of node, HTML 5, etc that async and await isn't going to work with. So now you're going to have normal synchronous code, asynchronous code that looks synchronous, and other asynchronous code that can't be made to look synchronous.

I'm all for finding ways to avoid callback soup and to simplify asynchronous patterns. I think there are good ways to structure traditional callbacks that is sane and I think promises are a great step. I'm skeptical about async and await.

I have mixed feelings but I think this is a net win for JavaScript.

XMLHttpRequest was enhanced with the Fetch API which uses promises. The libraries and methods will eventually catch up in a similar way.

If we stopped here there'd be little reason to ask everyone to promisify their libraries. The promise callback chain was only slightly more easy to read than the callback pyramid of doom. You might say that async/await lowers the explicit complexity vastly and increases the implicit complexity marginally.

the point of promises was to have a standard contract for callbacks, including error handling, and that contract can be passed around, listened on later, etc. It was a drastic improvement over callbacks. Async/await is just minor sugar over that to make your eyes happier. You still need to reason about the code the same way. You still need to remember they're promises (so you can, let say, await Promise.all(...) to avoid waiting on every single step individually). It doesn't really "add" anything. Promises did.

Too bad promises had a lot of glaring flaws that are taking forever to fix (or are unfixable). We're just getting to the point where unhandled errors are dealt with properly. Composing promises with non-promise constructs still suck. There's still only 2 paths (success and error). The flatMapLatest scenario still suck.

Still, promises were the improvement. Async/await is just sugar.

No. Those two have real world advantages that allow you to do things you previously could not.

This is just pointless syntax.

JIT compilers.

Reply on news.ycombinator.com