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

181–190 of 227 posts

Re: JavaScript async/await implemented in V8

#181

Post by Bognar »

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…

In addition to the answers already given, I think it's important to notate that a function is async in the signature rather than requiring the user to scan the entire method looking for an "await" keyword.

Re: JavaScript async/await implemented in V8

#182

Post by norman784 »

BrandonM wrote: post #158
coldtea wrote: post #153

Earlier quoted context omitted.

As I wrote in depends whether you can survive and continue from an exception inside the .then to the next step or not -- not about how the promise would handle an exception, but whether you want it to handle it or you want to survive and handle it yourself. e.g, naive example: .then(() => { var foo; try { foo = getFoo(); } catch (err) { foo = 10; //some default value } return foo; }).then( (foo) => etc. So you might…

That example could be written: .then(getFoo) .catch(err => 10) //some default value .then( (foo) =>

cool, learned something new

Re: JavaScript async/await implemented in V8

#183

Post by masklinn »

amelius wrote: post #179
masklinn wrote: post #164

Earlier quoted context omitted.

In javascript it would yes (actually a `yield*`, or an `await` in async/await). With native coroutines it wouldn't (the runtime would implicitly yield on IO). > But what if I want the fetch() function to decide whether to yield or not? In javascript? The question doesn't really make sense, a function is either sync or async.

> The question doesn't really make sense, a function is either sync or async. Well, either fetch() blocks, or not. If it blocks, then it should yield, its caller should yield, etc. If it doesn't block, then it can just run to completion.

Don't elide important parts of the quote. In javascript your question doesn't make sense.

> Well, either fetch() blocks, or not.

Javascript functions always block.

> If it blocks, then it should yield, its caller should yield, etc. If it doesn't block, then it can just run to completion.

If a function is async, you must yield[0]. It may not need* that capability (conditionally) and doesn't have to yield at all e.g.

    function*() {
        return 4;
    }
is valid and will not suspend. You must still yield*[0] on it so that it is properly resolved as a generator.

[0] I think that's not an issue for async/await as it's syntactic sugar for then chains, the code itself may be converted to a generator or whatever but it will embed the driver

Re: JavaScript async/await implemented in V8

#184

Post by Bognar »

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 don't see how it throws away the functional programming paradigm. This is basically Haskell's do-notation applied to JS Promises.

Re: JavaScript async/await implemented in V8

#185

Post by grandalf »

spb wrote: post #161
grandalf wrote: post #81

Earlier quoted context omitted.

is the non-awaiting one guaranteed to finish (assuming no errors)?

It's guaranteed to return as soon as the thread of execution finishes prior immediately-pending callbacks (since it's basically a synchronous function call with an awaited return value). It's "finished" as soon as it's finished initiating the send, since it doesn't await the result. (The exact point where this gets resolved, relative to other pending callbacks/resolutions, is a very wonky detail involving constructs…

Interesting!

Re: JavaScript async/await implemented in V8

#186

Post by dcherman »

rpastuszak wrote: post #140
spraak wrote: post #124

Earlier quoted context omitted.

This right here. One of my friends (a more experienced developer) told me at coffee one day, "I use const for everything" which really stuck with me. It really helps make it clear if you need a mutation to have let stand out.

However, it's worth noting that using const doesn't make variables immutable. It only protects them of being reassigned: const val = 'a'; val = 'b'; // TypeError const obj = { val: 'a' }; obj.val = 'b'; // This line will still work. obj = { val: 'b' }; // TypeError

Yep. In those cases, I still prefer let personally even though I know the variable itself will not be re-assigned, kind of as an indicator that I expect the referenced object to be mutated.

Re: JavaScript async/await implemented in V8

#187

Post by cwmma »

gpderetta wrote: post #178
cwmma wrote: post #177

Earlier quoted context omitted.

escaped/non-escaped variables are not a thing in JS

There are no locals in JS (honest question)? If that the case you have to assume that everything can be mutated everywhere unless for those functions that explicitly and fully document their side effects (and yield would certainly be a side effect).

variables declared with the var keyword are functionally scoped in JS so they are local to the function they are declared in and are lexically scoped to the closure of that function. So your local variables you can be fairly confident are not mutated anywhere else.

That being said you can totally have globals and whatnot that can be mutated anywhere (e.g. parameters passed to a function or literal globals installed in the global scope) or things declared at a lower scope that can still be modified by multiple functions.

Hope that clears it up

Re: JavaScript async/await implemented in V8

#188

Post by Sir_Cmpwn »

189723598 wrote: post #142
egeozcan wrote: post #113

Earlier quoted context omitted.

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.

I object to this. The .NET Framework is top tier and sets a high bar for standard libraries, in my opinion. It also runs on any OS just fine, especially now that Microsoft's own implementation is open source and MIT licensed. The community is also very strong with tons of docs and libraries and SO Q&As and plenty of jobs and local user groups. And if you don't like the C# boilerplate, F# has all of the same benefits.

Enough with the FUD around .NET/C#, I'm a full time Linux greybeard and even I'm sick of it.

Re: JavaScript async/await implemented in V8

#189

Post by candu »

dcherman wrote: post #186
rpastuszak wrote: post #140

Earlier quoted context omitted.

However, it's worth noting that using const doesn't make variables immutable. It only protects them of being reassigned: const val = 'a'; val = 'b'; // TypeError const obj = { val: 'a' }; obj.val = 'b'; // This line will still work. obj = { val: 'b' }; // TypeError

Yep. In those cases, I still prefer let personally even though I know the variable itself will not be re-assigned, kind of as an indicator that I expect the referenced object to be mutated.

Coming from a background that includes some experience with C / C++, `const` here works as I expect it to. I'd prefer `const` even for the object reference case: I get errors on reassignment this way, and presumably it makes additional optimizations possible. To each their own, I suppose :)

There's also `Object.defineProperty()`, `Object.freeze()` for more control over mutability.

Re: JavaScript async/await implemented in V8

#190

Post by jdc0589 »

skrebbel wrote: post #115
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.…

I don't see that as a downside. Callbacks make sense for the pipelining portion of async streams. I usually wrap things up such that i set up my callback/event based stream pipeline, and then have a promise that gets resolves on completion/end. That way your stream code is 100% normal callbacks, and you still have promises/async/await for overall flow control.
Post reply on HN