Live data from Hacker News

JavaScript async/await implemented in V8

chromium.googlesource.com

101–110 of 227 posts

Re: JavaScript async/await implemented in V8

#101
post #28

Earlier quoted context omitted.

Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…

Nit -- you want: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ].map(promise => promise.then(res => res.json()))); } catch (err) { console.log(err) } } As written you get "Promise.all(...).map is not a function"

[deleted]

Re: JavaScript async/await implemented in V8

#102
post #28
post #16

Earlier quoted context omitted.

> (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) How about: async function main () { try { const responses = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]); const jsons = await Promise.all(responses.map(res => res.json())) } catch (err) { console.log(err) } } I think this is pretty clear and not needing any lib…

Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…

You should put the json parsing inside the Promise.all.

Re: JavaScript async/await implemented in V8

#103

Thank you to Microsoft and Anders Hejlsberg for inventing Async/Await (and to F# for the original inspiration) https://en.wikipedia.org/wiki/Futures_and_promises

async/await as we know it actually came from Midori's C# dialect, which indeed was inspired from F#: http://joeduffyblog.com/2015/11/19/asynchronous-everything/ (Although, just to be pedantic, the concept of futures is way older than F#. Alice's syntax, for example, is pretty close)

The nice part about F#'s async implementation is that it was purely a library. I wish languages aimed at allowing developers to build things for the language, rather than providing more compiler built-ins. Making it extensible is more elegant (though I understand it might be easier to optimize perf).

Re: JavaScript async/await implemented in V8

#104

From all my research, I feel like Promises end up making better code than async await. Am I the only one who thinks that? Like, what's the equivalent of Promise.all with async/await? And how do tou do stuff synchronously after kicking off an async process?

I haven't written any async/await code yet, but since it's just sugar over promises, wouldn't you just do "await Promise.all(...)"?

Yup. Promise.all() returns a new Promise which settles after every Promise in the provided array has settled (or throws after one of the provided Promises throws).

Re: JavaScript async/await implemented in V8

#105
post #28

Earlier quoted context omitted.

Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…

Nit -- you want: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ].map(promise => promise.then(res => res.json()))); } catch (err) { console.log(err) } } As written you get "Promise.all(...).map is not a function"

Oh you're right of course. My mistake.

Re: JavaScript async/await implemented in V8

#106
post #42
post #18

Earlier quoted context omitted.

I am willing to admit that async/await is a bridge between the Node and .Net communities -- surmounting this means we are that much closer to literally doubling the developer pool for either sections of the community.

how so? I like the JS async/await a lot, but you couldnt pay me to write .net I personally don't know many devs who would choose to learn a new lang because of a feature (assuming that they didn't want to learn it before it existed)

I held my nose when I was forced to write JavaScript until I learned about async/await.

I came from a language that can do this kind of thing implicitly using coroutines (i.e., I could write imperative code that would pause on a network request and resume afterwards). Have to wade through callback hell -- even with Promises -- was a serious step down.

With async/await being explicit, combined with functionality like Promise.all(), this is actually a better solution than I had before, because I can spawn a dozen queries at once and wait for them all to complete before I continue. I've used that to good advantage already once with an await Promise.all(...) call, and the patterns are so easy to follow that it brings tears to my eyes.

Or I can inject more traditional callbacks when the logic would be easier (or when it would allow several simultaneous calls to complete), which does happen from time to time.

As to whether I'd learn a new language because of it: I'm considering learning Elixir because of even stronger guarantees [1], actually, so yes, I would.

[1] Apparently in addition to being able to write code using light threads like this, you can also put a cap on how long the VM will run code, so if some idiot developer puts a loop in the code that doesn't return control enough, instead of destroying your UI experience it will just pause that loop and resume the main loop. Still have yet to try it though.

Re: JavaScript async/await implemented in V8

#107
post #66
post #50

Earlier quoted context omitted.

Yes. They will be sent into map immediately, and Promise.all() will return a Promise which will settle when the mapped array is all settled (or one errors, but that's not really relevant to the question). We're really just awaiting the promise returned from Promise.all(), but mapping the original fetches into a "new" set of promises.

I'm sorry, but I don't see why/how they would be sent to `map` immediately, given where the parenthesis are in the above code snippet. `Promise.prototype.map` isn't a builtin function is it? If the `map` call was inside the invocation of `Promise.all` then I could see it, but perhaps I am missing something.

No, you're right. That was a mistake on my part. The .map() should be called on the array, as calebegg pointed out.

Re: JavaScript async/await implemented in V8

#108

Earlier quoted context omitted.

Nit -- you want: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ].map(promise => promise.then(res => res.json()))); } catch (err) { console.log(err) } } As written you get "Promise.all(...).map is not a function"

Just to put it out there, an ES6 implementation using async.js would look like async.parallel({ facebook: done => request("https://api.github.com/orgs/facebook", done), twitter: done => request("https://api.github.com/orgs/twitter", done) }, (err, responses) => console.log(err, responses); ); And output something like: null, { facebook: { // facebook data }, twitter: { // twitter data } } Sure it suffers from a third…

This is not the same at all. Any error in any of the callbacks is not catchable with one catch statement (you need separate try catch statement in every one of your callbacks). With async/await and promises, you only need one catch statement or one .catch method in one place because of proper error propagation and composition.

Re: JavaScript async/await implemented in V8

#109
post #51

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

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); //

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.

Re: JavaScript async/await implemented in V8

#110
post #29

Kinf of OT, but can anyone share their experience about using Babel's async/await in production instead of regular Promises? I'd love to hear about people who have used it in large and complex projects, from a debugging standpoint. As of now, using Bluebird (with its source in a different, blackboxed script), it is possible to follow the code execution through the event loop with async debugging, in a very elegant an…

[deleted]
Post reply on HN