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

111–120 of 227 posts

Re: JavaScript async/await implemented in V8

#111

Post by masklinn »

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.

> IMHO all this could be done automatically by language.

Not backwards-compatibly. You'd need to make every function async and every value a future/promise (semantically at least, then optimise most cases back to sync somehow, which incidentally means possible behavioural changes based on what the optimiser manages or doesn't manage to syncify).

Re: JavaScript async/await implemented in V8

#113

Post by egeozcan »

mkoryak wrote: post #42
ihsw wrote: 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 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?

Re: JavaScript async/await implemented in V8

#114

Post by garyclarke27 »

sotojuan wrote: post #57
viperscape wrote: post #19

Earlier quoted context omitted.

The try and catch inside the async function is also great. Curious though, is using const over let common? I usually use const for imports and module level globals, and let inside functions. I recently got back into javascript, and it's nice to see it flourishing.

I'm alone in this but I prefer `let` over everything else unless it's something like Redux action strings, database connections strings, or anything of the like. I rarely use `const` for the ridiculous reason that I find it too long (5 characters!). `let` is short and reads nicely and my programming style in general never mutates stuff anyway (I use Ramda/always return new data). That said, `const` is picking up to b…

As you admitted, your behaviour is rediculous, hope for your sake, your boss or customers don't read this.

Re: JavaScript async/await implemented in V8

#115

Post by skrebbel »

xanderjanz wrote: post #92

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'm not sure you fully grok async/await then. Thing is, using async/await means using promises. You can't use async/await without promises. An async function returns a promise. Always. (in a way, `async` can be seen as something of a type annotation).

If you want to use async/await with something that's asynchronous but not Promise based, you'll first need to convert it into a promise before you can async/await it. This is actually very elegant in my opinion: instead of proposing yet another way to do asynchronicity in JS, async/await fully embraces Promises, which you already know.

Of course, this means that async/await also has all of Promise's downsides. For example, you can only resolve a promise once, so neither Promises now async/await make dealing with streams of asynchonous events any easier.

Re: JavaScript async/await implemented in V8

#117

Post by barrkel »

MichaelGG wrote: post #103
Lx1oG-AWb6h_ZG0 wrote: post #84

Earlier quoted context omitted.

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

Integrated features are easier to tool and provide good diagnostics for. It's nice to have enough expressiveness to model monadic computations without too much syntactic overhead - and monads are usually enough, since they hand blobs of user code to the library to be composed as necessary - but debugging a reshuffled graph of closures is no picnic.

Re: JavaScript async/await implemented in V8

#118

Post by dclowd9901 »

I think my problem with this approach is the way it throws away the functional programming paradigm JS has been sharpening over these last few years. When I see await, I'm reminded of Java or .net, languages that didn't traditionally have functions as first class citizens.

OTOH, I can't complain about removing dependencies like "when" or "bluebird", and it'll be nice to not have to simulate promise returns in testing.

Re: JavaScript async/await implemented in V8

#119

Post by dvlsg »

dclowd9901 wrote: post #118

I think my problem with this approach is the way it throws away the functional programming paradigm JS has been sharpening over these last few years. When I see await, I'm reminded of Java or .net, languages that didn't traditionally have functions as first class citizens. OTOH, I can't complain about removing dependencies like "when" or "bluebird", and it'll be nice to not have to simulate promise returns in testing…

I think it's nice to have both options. I prefer the functional style of chaining promises for the most part, but there are definitely a few times when await is easier to use IMO (awaiting inside of a loop, for example).
Post reply on HN