`async`/`await` and Node

[benjamingr]

Async/await has landed in V8, details are being worked out. This is a feature many users have been waiting for and I suspect many will use.

We need to figure out how to work with it in core, namely:

• We need to finally make up our mind about what happens when promises throw and there is no catch handler attached in a reasonable time span.
• We need to figure out how core would work with async functions would work in core and with core functions.
• The CTC need to make a decision about Adding Core support for Promises node#5020 and consider how (and if) it would work with async functions.
• Node core might want to be involved in proposals regarding typed catch and other proposals that are needed for async/await to work in Node.
• We need to solve the promises related post-mortem issues. Creating a promise no longer requires using the word "Promise" anywhere - all you have to do is (async () => {})(). Post-mortem core-dump users would have to run a transform on their code forbidding async and await otherwise.

I would also love to see async/await in the context of Node discussed in the next TC meeting if possible. Our window of action is rapidly closing and if there is a grave mistake we need to find it asap.

[i5ting]

nice job

[benjamingr]

Going to get some people talking here since this requires attention and I think a lot of collaborators are unaware, cc @nodejs/collaborators

[bmeck]

Note: TC39 has been discussing, but has not formally proposed "top level await" for Modules.

[yorkie]

I'm -1 on adding a ES feature which is landed at v8 but not as a finished proposal. BTW, do we need to consider the https://github.com/nodejs/node-chakracore as well?

[bmeck]

@yorkie async functions are proposed in https://github.com/tc39/proposals and have advanced pretty far, top level await is await outside of async functions.

[yorkie]

@bmeck I mean the finished proposal, which has no items about async function, and the async function feature is currently in the stage 3.

Let me know if I'm wrong :-)

[bmeck]

@yorkie Stage 3 means it is going to land, pending implementation problems / concerns for environments. That means it is the appropriate time for Node to get involved and the last chance to voice concerns before it lands in ECMA262.

[ChALkeR]

@yorkie I would prefer us not moderating language features that landed in v8 at our end. Also, most likely the proposal will be accepted (stage-4) before async functions will be enabled in v8 by default (i.e. without a flag).

[benjamingr]

@yorkie if Node waits until the ink is dry then it has no chance to bring issues up - that has been a big pain point before.

Async await already landed in ChakraCore a while ago.

We need to make sure we're ready and need to expect at least some widescale adoption as this feature has seen in C#.

[vkurchatkin]

@benjamingr I don't think that async-await actually requires special treatment, so the fact that it's in v8 shouldn't change anything for core

We need to finally make up our mind about what happens when promises throw and there is no catch handler attached in a reasonable time span.

If anything, this is less important for async-await, because everything has rejection handler, except top level promise.

We need to figure out how core would work with async functions would work in core and with core functions

Nothing to decide, async functions are just functions that return promises.

Node core might want to be involved in proposals regarding typed catch and other proposals that are needed for async/await to work in Node.

Why is it needed for async-await? Try-catch is not something new.

We need to solve the promises related post-mortem issues

Also not something new. I seriously doubt that someone actually monkey-patches promises to have post-mortem support.

Our window of action is rapidly closing

Seems like a huge overstatement. What worst case scenario you have in mind?

[mikeal]

I don't think it sets a good precedent to disable features V8 has landed. We have traditionally looked to V8 to define its own stability level and take it "as is." This opens up a big can of worms and potentially endless bike shedding and second guessing of V8 which I don't think we want to get into.

[trevnorris]

We can't "disable" this feature. Because it's not an API. It's syntax. We can not support it by not returning promises.

[mikeal]

We can not support it by not returning promises.

People wrap our APIs in promises, including the native ones ship with. With await landing we can only expect that to increase. The burden of supporting these use cases in core, whether we return promises in core APIs or not, will increase with the increase in usage in the ecosystem and there isn't much we can do about it.

[jasnell]

Debating whether or not we want to support a syntax level feature is not
going to be worthwhile. Yes, we need to improve the promises story in core
but they're here to stay and so is async/await. At this point the
discussion needs to be how do we best support it or how do we limit
negative impact.
On Jun 15, 2016 8:28 AM, "Mikeal Rogers" notifications@github.com wrote:

We can not support it by not returning promises.

People wrap our APIs in promises, including the native ones ship with.
With await landing we can only expect that to increase. The burden of
supporting these use cases in core, whether we return promises in core APIs
or not, will increase with the increase in usage in the ecosystem and there
isn't much we can do about it.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#7 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAa2eUlGM_gg3d7SVZUSEJuJmc99TaVwks5qMBorgaJpZM4IyN9w
.