DEV Community

Discussion on: Sh*tpost: can we stop saying "syntactic sugar"?

View post

Replies for: It's called syntactic sugar because it doesn't introduce any substantial new feature to the language, it's just a sweeter syntax. So yes: destruct...

Collapse
 
togakangaroo profile image
George Mauer •

You are incorrect about async/await in javascript (and actually in every language that I've looked into the implementation). It is internally just unrolling promises yielded from a generator function.

I was doing this with my own code and libraries like co for years before async/await became popular. I think even q had a version of the concept. The experience was almost identical to async/await - you just had to use do co(function * () { ... }) instead of async function() { } and yield instead of await. The fact that it was such a simple swap-in was one of the major reasons that I and many others opposed the introduction of those features.

Collapse
 
sudojoe profile image
Joseph Locke • • Edited

async/await is not equivalent to using promises. It provides fundamentally different functionality by wrapping promises with a generator. It is important to recognize the difference, because it affects error handling in a significant way.

Consider:

const doSomething = () => {
  somethingElse().then(() => anotherThing());
};
Enter fullscreen mode Exit fullscreen mode

In this example, if somethingElse() or anotherThing() throw an exception, we would want doSomething() included in the stack trace, since that's where somethingElse() and anotherThing() are called from. In order to do that, the Javascript engine has to capture and store a trace of the stack where doSomething() is called before moving into somethingElse() since it will be inaccessible after somethingElse() is on the stack. That operation consumes both memory and time.

Now consider:

const doSomething = async () => {
  await somethingElse();
  anotherThing();
};
Enter fullscreen mode Exit fullscreen mode

Using await, there is no need to copy and store the current stack context before the execution of somethingElse(). Simply storing a pointer from somethingElse() to doSomething() is sufficient: during the execution of somethingElse(), doSomething() is still on the stack with its execution suspended, so it's available from inside somethingElse(). If somethingElse() throws an exception, the stack-trace can be reconstructed by traversing the pointer. If anotherThing() throws an exception, the stack-trace can be reconstructed as normal, because we are still within the context of doSomething(). Either way, capturing and storing a stack trace in memory before doSomething completes is no longer necessary, and constructing a stack-trace only happens when its necessary, i.e. an actual exception was thrown from somethingElse() or anotherThing().