Live data from Hacker News

V8 adds support for top-level await

chromium.googlesource.com

31–40 of 310 posts

Re: V8 adds support for top-level await

#31

Earlier quoted context omitted.

Hate to be a wet blanket, but that second code sample won't work. The function doesn't return anything so $ === undefined. Even if it did, this in that context is bound to the global object, so is the same as setting a variable without var or let. A proper example of IIFE for lexical scoping would be something like this: var numbers = ""; (function(){ for (var i=0; i Nowadays of course you could just use let instead…

Hate to dry off the blanket but they just forgot the `new` keyword for `this` ;) var $ = new (function() { this.version = '1.2.3'; })(); console.log($.version); // '1.2.3' EDIT: Or if you really want to abuse the spec var $ = (function() { if (!(this instanceof arguments.callee)) return new arguments.callee(); this.version = '1.2.3' })(); console.log($.version); // '1.2.3'

lol. But yes, I do really want to abuse the spec. You could also do this:

    var $ = (function(){ this.version = '1.2.3'; return this; }).call({})
    console.log($.version); //1.2.3
But that's not quite as ugly so I guess I lose some points.

Re: V8 adds support for top-level await

#33

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

Despite other deficiencies, JavaScript devs are generally pretty good at writing async code, for the simple reason that you get burned suuuper quickly if you try to mutate state outside of an async context when doing things like adding click handlers. This is something most front-end devs learn pretty quickly since it's such a fundamental part of writing JavaScript.

Re: V8 adds support for top-level await

#34
post #9

This is huge! Finally no more need to use IIFE's for top level awaits

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?

I think the boon here will be for scripts that run once. Say I just want to query a few tables. Now, I no longer need a `main()` wrapper:

  const result = await db.events.find();
  console.log(result);
That's my whole script

Re: V8 adds support for top-level await

#35
post #9

This is huge! Finally no more need to use IIFE's for top level awaits

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?

Or my preferred (gross) version:

    void async function main() {
       // code
    }()

Re: V8 adds support for top-level await

#37

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

In a single-threaded universe, what more do you need to lock the world than a boolean variable?

Re: V8 adds support for top-level await

#38

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

Since it’s all single-threaded, you can write your own locking primitives and they will work correctly.

Re: V8 adds support for top-level await

#39

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

I don't know if you intended to, but it comes across as arrogant and dismissive.

Dealing with asynchrony has been the an issue in JavaScript from the beginning, as the fundamental model is event driven.

There are a number of mechanisms for coordinating work, including mutexes (see Atomics.wait()), but for >99% of code, Promises are a better option.

Re: V8 adds support for top-level await

#40

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

Oh, you're going to love (hate) what I suspect will happen then:

> race conditions

I've gotten into multiple arguments with first-language-javascript devs who think race conditions can't happen in javascript "because it's not multithreaded". I'm thinking before they can accept this type of bug, it's going to get a new trendy name first, then all the old knowledge of "race conditions" continue to be ignored.

Post reply on HN