I promised Nolan a response on why I didnt particularly agree with this post when I merged it, figure may as well here.<p>I think all the caveats applied to async function (ensure its inside a try/catch, dont use for in) points to how complicated it can be, <a href="http://jakearchibald.com/2014/es7-async-functions/" rel="nofollow">http://jakearchibald.com/2014/es7-async-functions/</a> had to be amended with notes because a bunch of people very familiar with this style of coding still get it wrong. I cant see myself explaining to a new programmer how this all works.<p>I would really like to see us return to nice obvious blocking functions, taking the example the simplest way of all seems to be ...<p><pre><code> let db = new PouchDB('mydb');
let result = db.post({});
let doc = db.get(result.id);
console.log(doc);
</code></pre>
Let workers (or whatever equivalent they come up with in node) to make sure we dont block a single event loop and live happily ever after.<p>Basically copy erlang, but without actually having to use erlang.
I like that we're all starting to wake up from this callback nightmare in pretty much every language. It's funny to me that it took us going through a full blown callback orgy for us to realize that all we wanted to begin with was an abstraction of spawning threads and doing non-blocking i/o (makes sense, having to reason about locking is, often, unnecessary). I realize callbacks/lambdas have their place, but it was really starting to chaff.
Cool and concise article.<p>This is just me thinking out loud, but the look-ahead...will it ever end? You say ES7 is bleeding edge, but that's contingent on the context. In terms of browser support/widespread adoption right now, ES6 is bleeding edge. How many years...<i>decades</i> is something like ES7 away from ever being implemented in the majority of browsers out there? How much more will the web development landscape have even changed by then?
Does this offer any benefits over building coroutine functions with generators? The "co" library (and probably some others) do this.<p><a href="https://github.com/tj/co" rel="nofollow">https://github.com/tj/co</a><p>It seems mostly like a syntactical difference to me - with coroutines you "yield" instead of "await." You can still wrap things nicely in try{} catch{} blocks.<p>But the readme for co does mention that it's a stepping stone towards async/await. I like that ES7 will allow us to write this style of function without including an additional library, but apart from that, is there a big gap in functionality between the different approaches?
> However, promisey code is still hard to read, because promises are basically a bolt-on replacement for language primitives like try, catch, and return<p>I find promises quite readable when combined with arrow functions. async/await certainly is nice, but the difference in readability doesn't seem that big to me.
Seems like there are a lot of edge cases described in this article that could be confusing when using async/await. Is anyone else feeling ambivalent that async/await is actually a nicer syntax than just using promises?
await* is awesome too:<p><pre><code> let arr = [/* an array of promises *]
await* arr;
</code></pre>
Essentially the same as Promise.all<p><pre><code> let arr = [/* an array of promises *]
await Promise.all(arr)</code></pre>
I'm using channels (with the awesome js-csp lib) for managing server-side asynchronous code and so far it's really good. As a bonus I can use transducers with generators :)