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

41–50 of 227 posts

Re: JavaScript async/await implemented in V8

#41

Post by coldtea »

Bahamut wrote: post #36
norman784 wrote: post #22

Earlier quoted context omitted.

The think about using async/await its to write less code, make it much simple and makes also easy to try/catch errors. The think I don't like about promises its that you need to write a lot of lines that you could avoid with async/await, i.e: new Promise(function(success, failure){ db.fetch('sql...', function(err, data){ if (err) failure(err) else success(data) }) }) VS var data = await db.fetch('sql...') Also if you…

To correct this a little, the proper way to catch with promises is .catch, not with a try-catch inside a .then - that is an antipattern. The promise examples as written are not proper promise usage. I'm also in the boat of confused people of why is async-await requested by a good portion of the js community - wrapping the block within the function in a try-catch seems like a bad idea, a brute force mechanism. IMO thi…

>To correct this a little, the proper way to catch with promises is .catch, not with a try-catch inside a .then - that is an antipattern.

Depends whether you can survive and continue from an exception inside the .then to the next step or not.

Re: JavaScript async/await implemented in V8

#42

Post by mkoryak »

ihsw wrote: post #18
hoodoof wrote: post #5

This news is almost as important as the rest of ES2015 being implemented in Webkit. async/await is the final piece in the puzzle of providing real solutions to callback hell in JavaScript.

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)

Re: JavaScript async/await implemented in V8

#43

Post by coldtea »

PeCaN wrote: post #21
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…

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

Re: JavaScript async/await implemented in V8

#45

Post by AgentME »

avodonosov wrote: post #30

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

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!

Re: JavaScript async/await implemented in V8

#47

Post by awalGarg »

coldtea wrote: post #38
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…

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.

Re: JavaScript async/await implemented in V8

#48

Post by spriggan3 »

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 "tons of libraries" argument doesn't make tons of sense either.

It absolutely does make sense. How many "class builders" have been written in the JS community since ES6 got classes ? That's right. Now you don't have to rely on co/thunk and what not to write readable async logic. Promises are still callbacks wrapped in objects. Now the consumer of a function that returns a promise doesn't have to deal directly with the promise anymore.

This feature is something JS should have had a long time ago, no question.

> This feels like a step toward added confusion rather than language unity.

Things like prototypical inheritance are the biggest source of confusion, along with "this" behavior.

> beneath native abstractions

The correct terminology here would be syntactic sugar.

Look you might not like this, but what is better ? community fragmentation with transpilers and what not, or a single language that answers most of the needs of the community ? libraries that handle complex abstractions or documented syntax that allows getting rid of these poorly documented and poorly maintained libraries? I don't want to use generators to mimic corroutines and depend on co/thunkify to write readable async code. I don't want to use 3rd party language X or Z that will get me the syntax I want, I want everybody to use the same language without obscure patterns.

Re: JavaScript async/await implemented in V8

#49

Post by mkoryak »

wwwtyro wrote: post #32
avodonosov wrote: post #30

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

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

Re: JavaScript async/await implemented in V8

#50

Post by dvlsg »

coldtea wrote: post #38
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…

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.

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.
Post reply on HN