Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript async/await implemented in V8

chromium.googlesource.com

Post reply on HN
Print view View original

71–80 of 227 posts

Re: JavaScript async/await implemented in V8

#71

Post by zzzcpan »

andrewstuart2 wrote: post #15

I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't…

I think anyone with a fair amount of experience in complex asynchronous programs can agree with you. But most people don't have that experience and things look very different to them. They don't understand yet why their sequential database queries do not matter, they don't understand that it's not where the complexity is and that seeking familiarity and "prettifying" simple code with syntactic sugar is not going to make it simpler or easier to understand and maintain. They will have to learn it the hard way.

Re: JavaScript async/await implemented in V8

#72

Post by PeCaN »

coldtea wrote: post #43
PeCaN wrote: post #21

Earlier quoted context omitted.

You'd like Tcl and various Perl libraries. Mojo (Perl event loop among other things) in particular has a very nice, straightforward event flow quite reminiscent of Q. async/await looks nice but doesn't scale. As soon as you have to do something other than wait for a callback it falls apart.

> async/await looks nice but doesn't scale. As soon as you have to do something other than wait for a callback it falls apart. Waiting for a callback is what you do 90% of time. For the rest, you can always combine async/wait with Promises...

Maybe if the only thing you do is Ajax. Writing a server, a web crawler, a P2P protocol, heterogeneous OpenCL computations, etc, and you're going to need something a little more heavy-duty.

Re: JavaScript async/await implemented in V8

#73

Post by ben_jones »

calebegg wrote: post #68
dvlsg wrote: 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"

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 party dependency and I would argue its slightly less concise, but we're getting to the point of opinionated API's just like some developers prefer promises, some will prefer async/await, others will continue with vanilla callbacks.

Re: JavaScript async/await implemented in V8

#74

Post by girvo »

awalGarg wrote: post #47
coldtea wrote: post #38

Earlier quoted context omitted.

Would it? IIRC Promise.all will run the two responses in parallel, but will not send the first into the map before both are finished.

Promise.all doesn't "run" anything. Promises "run" the very moment they come into existence. Promise.all simply tells you if and when all of them are settled. It depends on your Promises whether they are doing something outside the single threaded event loop or not for them to be parallel or not.

> Promises "run" the very moment they come into existence

Which is why I'm a massive fan of Futures from ramda-fantasy[0] instead of Promises for certain tasks!

[0] https://github.com/ramda/ramda-fantasy/blob/master/docs/Futu...

Re: JavaScript async/await implemented in V8

#78

Post by int_19h »

andrewstuart2 wrote: post #15

I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't…

The short answer is that async/await is to promises what loops were to if/goto. It's "just" syntactic sugar, but once you start using it, the code is much easier to write, and its structure is more obvious at a glance. It does not change the way you reason about asynchrony, because the underlying model is still the same. And you still need to understand that underneath, it's all promises and continuations. But there are very tangible benefits to be had from this kind of syntactic sugar.

This is speaking from personal experience, albeit not in JS, but rather .NET. However, the story there is similar - .NET used callback-based continuations first (the Begin... pattern), then added promises (Tasks) in .NET 4.0, then finally async/await syntactic sugar in C# 5. We introduced tasks to our codebase pretty soon, but had to avoid await for a while because of the requirement for the code to be compilable with C# 4. When we finally dropped that requirement a couple of years later, and started moving to await, code became much simpler and cleaner as a result, and new code is also much easier to write, with fewer silly mistakes (like "I forgot to check for errors").

Re: JavaScript async/await implemented in V8

#80

Post by woah »

PeCaN wrote: post #72
coldtea wrote: post #43

Earlier quoted context omitted.

> async/await looks nice but doesn't scale. As soon as you have to do something other than wait for a callback it falls apart. Waiting for a callback is what you do 90% of time. For the rest, you can always combine async/wait with Promises...

Maybe if the only thing you do is Ajax. Writing a server, a web crawler, a P2P protocol, heterogeneous OpenCL computations, etc, and you're going to need something a little more heavy-duty.

I'm writing a p2p protocol and you are wrong. Async/await is compatible with promises and the tooling around them, but for 90% of cases it is much more understandable.
Post reply on HN