3 ms·

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

spriggan3 10y ago
> 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-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
wwwtyro 10y ago
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.
- mkoryak 10y ago
  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
perrin4869 10y ago
how would that work?
AgentME 10y ago
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!
jeswin 10y ago
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; }
- grandalf 10y ago
  is the non-awaiting one guaranteed to finish (assuming no errors)?
  - spb 10y ago
    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-schedules/ 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').
    - grandalf 10y ago
      Interesting!
masklinn 10y ago
> 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).

spriggan3 10y ago

> 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-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

wwwtyro 10y ago

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.

mkoryak 10y ago
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

perrin4869 10y ago

how would that work?

AgentME 10y ago

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!

jeswin 10y ago

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; }

grandalf 10y ago
is the non-awaiting one guaranteed to finish (assuming no errors)?
- spb 10y ago
  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-schedules/ 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').
  - grandalf 10y ago
    Interesting!

masklinn 10y ago

> 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).