Yes, async/await solves one problem in particular that generators alone
cannot—the ability to `await` some asynchronous value from within a true
generator (one yielding actual values, not a coroutine yielding promises or
thunks into a trampoline). These coro trampolines are a clever hack, but
the async/await syntax allows these two completely distinct language
features to become truly orthogonal. This is important in its own right,
but also has immediately utility (e.g. more elegant lazy streams using
for-of iteration).

On Thu, Sep 11, 2014 at 5:45 AM, Jeswin Kumar <jeswinpk at agilehead.com>
wrote:

> Looking at my project (in which asynchronous calls are entirely done
> via generators), I can't see how async/await would simplify code for
> end-users like me (application programmers).
>
> End users write the spawn()/Q.async()/co() wrapper *at most* one
> single time in an application:
> 1. When using a framework like say koajs, you don't have to write it even
> once.
> 2. While not using a framework, you'd have to use the wrapper one
> single time in say, the main.js file.
>
> To use the example at
> http://wiki.ecmascript.org/doku.php?id=strawman:async_functions
>
> async function chainAnimationsAsync(elem, animations) { CODE; }
> is just
> function chainAnimationsAsync*(elem, animations) { same CODE; }
> when flow control is done by a framework or at the entry point to your
> application. spawn() isn't needed.
>
> I can't see how this will reduce application's code even a little. So
> my question is, is async/await needed?
>
>
> One more question
> --------------------------
> 1. yield is practically very difficult to use in a project because you
> don't get proper stack traces (at least with the current flow control
> libraries). You'd only see the last call which threw the error, and
> then functions from the flow control library immediately below that. I
> suppose the generators leading up to the erring generator are all
> suspended and wouldn't be on the stack frame chain.
>
> 2. yield* generator delegation solves this problem, you get real stack
> traces. I was able to get full stack traces simply by replacing all
> yield X() with yield* X()
>
> example code as in: https://github.com/chopachom/syncio
>
> So if there are valid use-cases for adding async/await to JS,
> shouldn't it be based on how yield* works rather than yield?
>
> -- Jes
>
> The Fora Project is coming...
> https://github.com/jeswin/fora
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140911/a938d6b9/attachment.html>

Yes, async/await solves one problem in particular that generators alone
cannot—the ability to `await` some asynchronous value from within a true
generator (one yielding actual values, not a coroutine yielding promises or
thunks into a trampoline). These coro trampolines are a clever hack, but
the async/await syntax allows these two completely distinct language
features to become truly orthogonal. This is important in its own right,
but also has immediately utility (e.g. more elegant lazy streams using
for-of iteration).