Does async/await solve a real problem?

Domenic Denicola domenic at domenicdenicola.com
Thu Sep 11 05:42:08 PDT 2014


There are several problems solved by async/await instead of twisting generators:

1. What if you wanted to use generators for lazy sequences (iterables), instead of asynchronicity? If your framework assumes all generators are for async, you lose the original use case of generators.

2. Say what you mean. `function*` and `yield` mean something very different from `async function` and `await`, similar to how `Subclass.prototype = Object.create(Superclass.prototype); Subclass.prototype.constructor = Subclass` is different from `class Subclass extends Superclass`.

3. Operator precedence. You can do `await a + await b` to mean `(await a) + (await b)`, but `yield a + yield b` means `yield (a + (yield b))`.

4. Ability to produce promise-returning functions without buying into a specific framework that interprets generators in a certain way. E.g., you could use `async function f() { return 5; }` to return a promise for 5, which people can consume with `f().then(v => ...)`. If you try to do `function* f() { return 5; }` you will get an iterable, which is not understood to be asynchronous. (Hopefully my use of `return 5` for brevity instead of more complex code does not confuse this point for you.)

As for stack traces, long stack trace support is a debugging feature, and the fact that `yield*` gets them right now doesn't mean that `await` won't get them in the future.

-----Original Message-----
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Jeswin Kumar
Sent: Thursday, September 11, 2014 11:46
To: es-discuss at mozilla.org
Subject: Does async/await solve a real problem?

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


More information about the es-discuss mailing list