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

V8 adds support for top-level await

chromium.googlesource.com

Post reply on HN
Print view View original

151–160 of 310 posts

Re: V8 adds support for top-level await

#151

Post by tiglionabbit »

PetahNZ wrote: post #70
gregmac wrote: post #65

Earlier quoted context omitted.

> two sequential lines of code are no longer two truly sequential instructions I've done a lot of async/await and I really can't think of any situations where this has been a concern for me. If you're mutating state in method calls without explicitly passing it around, that might be an issue but that's a deeper design issue IMHO.

One use case I often find is a caching layer between JS and a HTTP call. If there are 2 calls to a non cached endpoint, the HTTP will fire off twice before caching the result. You can work around this by returning the first promise from the cache, but this is essentially a mutex. Having locking primitives would solve this and require less boilerplate code.

Caching the promise is a perfectly good solution. Locks aren't needed.

Re: V8 adds support for top-level await

#152

Post by tiglionabbit »

Scooty wrote: post #83
megous wrote: post #9

Earlier quoted context omitted.

It's nice, I guess, but huge? Instead of: async function main() { // code } main().catch(console.error); I'll be maybe writing: try { // code } catch (ex) { console.error(ex); } Hrm?

Top level await does more than remove a main function. If you import modules that use top level await, they will be resolved before the imports finish. To me this is most important in node where it's not uncommon to do async operations during initialization. Currently you either have to export a promise or an async function.

Do we really want slow imports though? If you have a bunch of modules with async setup functions, would you not be able to Promise.all() them?

Re: V8 adds support for top-level await

#153

Post by anonytrary »

11235813213455 wrote: post #6
danappelxx wrote: post #3

Earlier quoted context omitted.

What is an IIFE?

he should have said IIAFE actually (immediately-invoked-async-function-expression) (async () => { console.log(await 'hello world') })()

All async functions are functions, so not really.

Re: V8 adds support for top-level await

#154

Post by hombre_fatal »

earthboundkid wrote: post #90
aledalgrande wrote: post #71

Earlier quoted context omitted.

Maybe he meant why not const?

Const is a complete waste of time for non-primitive types. I defy anyone to show me a single bug in a popular program that could have been prevented by using const for a function local object. It can’t be done. There are bugs caused by mutatable state. There are bugs caused by reassigning globals. There has never been a bug caused by reassigning a function local variable while leaving it mutable.

Using the more restrictive construct until you actually need additional features (like identifier rebinding) is just engineering 101.

I think the onus would be on you to prove that using a less restrictive concept is worthwhile because it saves you two keystrokes. That, in contrast, seems like the opposite of good engineering. Like using classes over structs because class is shorter to type.

The more I think about your post, the more absurd it becomes.

Re: V8 adds support for top-level await

#156

Post by spankalee »

stagas wrote: post #148
Scooty wrote: post #83

Earlier quoted context omitted.

Top level await does more than remove a main function. If you import modules that use top level await, they will be resolved before the imports finish. To me this is most important in node where it's not uncommon to do async operations during initialization. Currently you either have to export a promise or an async function.

Oh that's interesting if this is the case. So now a module export can contain an asynchronously initialized db handler for example?

Please don't do that though!

Re: V8 adds support for top-level await

#157

Post by [deleted] »

matt-attack wrote: post #150
ihuman wrote: post #129

Earlier quoted context omitted.

Are you sure? From what I can find, async [0] causes a function to a return a promise, which then returns the result. Await [1] takes a promise, and waits for it to either be resolved or rejected. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> and waits for it Yes but that doesn’t mean other lines of code can’t be executing while waiting. The waiting isn’t truly blocking the entire application. Plenty of other things can be happening.

[deleted]

Re: V8 adds support for top-level await

#158

Post by pitaj »

Scooty wrote: post #88
pitaj wrote: post #25

Earlier quoted context omitted.

JS async is implemented as generators as well AFAIK

I'm not sure how they're handled internally, but async functions are no longer generators. For a while after generators and before async/await, generators were used as a polyfill.

Because of how similar they are, it would make sense to implement async/await using existing generator backends in the VM, right?

Re: V8 adds support for top-level await

#159

Post by anonytrary »

laughinghan wrote: post #94
mstade wrote: post #53

I think async/await probably makes more sense in a typed language, where a compiler can tell you when you're missing an await, or at least warn you about not dealing with potential side effects and error handling. For something like JavaScript, it'd make more sense to me to have the runtime always and implicitly await the result of async functions, and instead make developers explicitly say when they wish for the res…

I like your idea, but I don't see how it could work in an untyped language. Consider: function foo() { return 1; } function bar() { return fetch('http://example.com'); } // implicitly async function qux() { const fn = Math.random() > 1/2 ? foo : bar; fn(); return 1; } Is qux() synchronous?

The function is both synchronous and asynchronous until it is called by the caller. This is called Shannon's Cat.

Jokes aside, I'd like to add that just because a function returns a promise doesn't mean the caller will always want to wait for it to resolve. I think of `await` as a simple modifier that casts the return value from a `Promise` into `T`. By getting rid of the modifier, we can no longer assume that the caller wants to implicitly wait.

Post reply on HN