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

141–150 of 227 posts

Re: JavaScript async/await implemented in V8

#141

Post by tel »

brandonbloom wrote: post #100
andrewstuart2 wrote: post #98

Earlier quoted context omitted.

> It's been said that "callbacks are imperative; promises are functional". It's true. Furthermore, callbacks structure control flow and promises structure data flow. Do you have any good escapes l examples of further reading on this? I'm not sure I agree with this statement, or perhaps don't fully understand it. It seems like both cases boil down to functions as data (function pointers essentially) that are called at…

You can google that quote and find more, but the control flow vs data flow formulation is not widely discussed from what I've seen.

It's widely discussed in Haskell communities, fwiw ;)

Re: JavaScript async/await implemented in V8

#142

Post by 189723598 »

egeozcan wrote: post #113
mkoryak wrote: post #42

Earlier quoted context omitted.

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 don't understand. I also like JS async/await and like JS and node in general but .NET is simply beautiful IMHO (given you are using F# or C#). Why would you rather not write .NET code?

c# is a great language but many people don't want to have to specify type information so often or create classes so often. Even many statically-typed languages don't require as much List stuff. Also, everything outside of the language itself sucks. The frameworks, the operating system is has to run on, the community, etc.

Re: JavaScript async/await implemented in V8

#143

Post by tehbeard »

nailer wrote: post #132
startling wrote: post #7

Earlier quoted context omitted.

Is the syntax composable? Can I do const json = await (await fetch(https://api.github.com/orgs/facebook')).json(); or do I have to name it?

Tip: if you use anything other than fetch you'll just get JSON back immediately based on the MIME type, without the unnecessary conversion step.

Those other than fetch()s still do the "unnecessary conversion step". Don't dismiss fetch by the fact it doesn't hand hold or make assumptions.

It should be said that fetch() is quite low level call compared to what we've had before regarding ajax, so it makes sense in larger projects to wrap it to keep any logging, error handling and retry in one place.

Re: JavaScript async/await implemented in V8

#144

Post by nailer »

tehbeard wrote: post #143
nailer wrote: post #132

Earlier quoted context omitted.

Tip: if you use anything other than fetch you'll just get JSON back immediately based on the MIME type, without the unnecessary conversion step.

Those other than fetch()s still do the "unnecessary conversion step". Don't dismiss fetch by the fact it doesn't hand hold or make assumptions. It should be said that fetch() is quite low level call compared to what we've had before regarding ajax, so it makes sense in larger projects to wrap it to keep any logging, error handling and retry in one place.

> it doesn't hand hold or make assumptions

Using MIME types isn't hand holding or making an assumption.

Yes, people who need the low level features will wrap it with a series of competing high level libraries. It's a missed opportunity to make a standard, capable high level API though.

Re: JavaScript async/await implemented in V8

#145

Post by mstade »

ilkkao wrote: post #136
ch49 wrote: post #128

Why is "async" keyword needed? Can't JS engine infer from the use of "await" in a function that this function need to be async? I'm using async/await for a while now, and so many times I've introduced bugs in my code because i forget to put "async" in front of the function, or put "async" in front of wrong function. It's simply annoying to go back and put "async" when in middle of writing a function I realise I need…

Reason is mentioned here: https://github.com/tc39/ecmascript-asyncawait/issues/88#issu...

Thanks for this! Also later in that thread is an example to further bring home the point: https://github.com/tc39/ecmascript-asyncawait/issues/88#issu...

Solid reasoning, in my opinion.

Re: JavaScript async/await implemented in V8

#147

Post by a-saleh »

amelius wrote: post #139
tomp wrote: post #127

Earlier quoted context omitted.

Can anyone point to a good explanation why this is preferable to cooperative threads (coroutines)? I.e. the above code could easily be written as function main() { try { const res = fetch('https://api.github.com/orgs/facebook'); // yield here const json = res.json(); // yield here console.log(json); } catch (e) { // handle error } } and the runtime would automatically yield this coroutine and let other coroutines run…

Perhaps this is the reason: Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Last time I checked this was not allowed (?) Anyway, if so, I would strongly prefer this over a async/await construct, which is less general.

Is this the problem Python has solved with 'yield from' construct?

Re: JavaScript async/await implemented in V8

#148

Post by totemizer »

tomp wrote: post #127
tanto wrote: post #4

The moment I started using async await (with babel) combined with the new fetch API so many libraries got obsolete. Getting data is as easy as: async function main () { try { const res = await fetch('https://api.github.com/orgs/facebook'); const json = await res.json(); console.log(json); } catch (e) { // handle error } } So I am quite happy when this lands in modern browsers asap.

Can anyone point to a good explanation why this is preferable to cooperative threads (coroutines)? I.e. the above code could easily be written as function main() { try { const res = fetch('https://api.github.com/orgs/facebook'); // yield here const json = res.json(); // yield here console.log(json); } catch (e) { // handle error } } and the runtime would automatically yield this coroutine and let other coroutines run…

Probably not preferable. Async await works on top of promises...

Re: JavaScript async/await implemented in V8

#149

Post by coldtea »

BinaryIdiot wrote: post #88
coldtea wrote: post #44

Earlier quoted context omitted.

Probably in an upcoming Node 6 -- they do update the running version with the latest v8 releases IIRC.

That seems like a mistake to me. That would mean code that runs perfectly under, say, 6.5 would not run on 6.1. It should most certainly be a 7.x release.

For stability one should be using the LTS release.

And why would one downgrade from 6.5 to 6.1? If they code for 6.1 and want to not use LTS and to keep 6.1 installations around, then they should not use 6.5 features.

Re: JavaScript async/await implemented in V8

#150

Post by coldtea »

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.

What exactly would you need that you can't get with async/await or async/await+Promises?
Post reply on HN