Hacker News Reader

Comment by avodonosov | Hacker News Reader

what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.

View on HN

Because you don't always have to await a function, and it isn't always possible for the runtime or language to decide whether to "await" or not.

  /*
    The following code may or may not use an await.
    Not await-ing would be better user experience.
  */

  async function sendEmails(id) { ... }
  
  async function signUp(userData) {
    const user = await db.saveUser(userData);
    sendEmails(user.id); // <-- Not awaiting send to complete
    return "Congrats. Signup complete!"
  }


  /*
    On the other hand this code needs an await:
  */

  async function updateGlobalState(obj) { ... }

  async function doSomething(data) {
    await updateGlobalState(data); //await needed
    return global.x;
  }

Sometimes it's really useful to kick off an async function as well, do some other work in the meantime that doesn't require that async function to be done, then await the promise from the async method later on when you do need it to be done.

is the non-awaiting one guaranteed to finish (assuming no errors)?

It's guaranteed to return as soon as the thread of execution finishes prior immediately-pending callbacks (since it's basically a synchronous function call with an awaited return value). It's "finished" as soon as it's finished initiating the send, since it doesn't await the result.

(The exact point where this gets resolved, relative to other pending callbacks/resolutions, is a very wonky detail involving constructs not exposed at the language level, which varies from engine to engine in spite of what the standard says: https://jakearchibald.com/2015/tasks-microtasks-queues-and-s...)

Whenever the call resolves, even if the send does encounter errors, this function or its caller aren't going to know about it either way. That's why this kind of promise-abandonment is pretty bad design - I wouldn't be surprised if there's already a draft in the works for some kind of "use strict" option that causes warnings / crashes when synchronous code finishes with Promises unreferenced (or at least something in tooling / profiling to trace 'promise leaks').

Interesting!

> IMHO all this could be done automatically by language.

Not backwards-compatibly. You'd need to make every function async and every value a future/promise (semantically at least, then optimise most cases back to sync somehow, which incidentally means possible behavioural changes based on what the optimiser manages or doesn't manage to syncify).

> what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.

Not without Fibers. Javascript doesn't have Fibers though there an implementation in Nodejs.

What it changes is that you don't have to rely on yet another library anymore to get the behavior people mostly use yield for. I'm talking about co/thunk . While it doesn't solve the red/blue function issue [1], it makes writing async code a bit less tedious.

At the end of the day it will force everybody to return promises from async functions, rather than requiring callbacks,which is a good thing.

[1] : http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Async/await is syntax sugar for doing things asynchronously. Whenever you have an async call in your code, you have to consider how the state of the program can change during the passed time. Also, there are many places where you need a result synchronously, like when you're in the event handler for a mouse click and need to determine whether the event should be canceled. If you had an asynchronous call, then the call will finish after the event has finished dispatching!

I'm sure there's good reason, but I have the same question. I also don't understand the need to use promises in the construct. I'd love some clarity here.

async/await is just sugar around promises. when you await something, that something must be a promise.

coroutines are used to make your code appear to execute without a need for a callback, and in order to create a coroutine one must wrap the function doing the awaiting in a generator.

now, I am assuming (perhaps incorrectly) that the async keyoword marks the function for wrapping, and await lets you know where the yields should go. or something like that :)

of course, now thats its all native, I have no idea any more

how would that work?

Reply on news.ycombinator.com