Item — HN Reader

You're missing the point of `await`.

Await does change how your program is structured, unless we're talking about most trivial cases.

You can use `await` inside a `for` loop—can you do the same with callbacks without significantly re-structuring your code?

What is the “callback analog” of placing something in a `finally` block that executes no matter which callback in a nested chain fails? You'd have to repeat that code.

Await has a potential of simplifying the structure a lot, because it befriends asynchronous operations with control flow.

>And finally, "await" is only applicable when a single callback gets called once at the end. If you're passing a callback that gets used repeatedly (a sorting function, for example), then normal-style callbacks are still necessary, and not harmful at all.

Indeed, await is only for the cases when we abuse functions (because we don't know what we'll call, and we have to bend our minds). Passing the sorting comparator is the primary use of first-class functions.

3 comments

I'm not disagreeing with you at all.

I guess we're using "structured" in different ways. Libraries like TameJS do wind up creating structures to deal with for loops, in the same way you'd otherwise manually have to deal with. Likewise with exceptions (which I said are the main actual benefit to await, that can't be reproduced in normal callback routines).

You obviously have to write a bunch of "plumbing" code to do with "raw" callbacks, in complicated situations (like loops), which "await" does on its own -- and writing that plumbing is annoying, although there are libraries to help.

My only point is, the fundamental structure of your program, on a conceptual level, is still the same. Everything's still running the same way, in the same order. It's just more concise, with less plumbing of your own, using "await". So the micro structure is different with await, but the high-level structure is no different. You can't "abuse" callbacks in the way you can abuse goto. Maybe I should have made that clearer.

I see your point. Closures also don't affect structure on conceptual level, but I think they're pretty darn useful. By the way, async can affect things on conceptual level if you embrace[1] it (I posted this link somewhere below as well, but just in case you haven't seen it).

[1]: http://praeclarum.org/post/45277337108/await-in-the-land-of-...

There are other means of accomplishing what you are referring to, for example, the async module for node.js is really nice in terms of having loop workers, as well as flattening out callback structures.

I find that async.waterfall + SomeFunction.bind(...) are insanely useful with node.js ... I don't seem to have near the friction in node that I find when working in C# projects.

Very concise reply with solid examples. You've sold me!