Live data from Hacker News

V8 adds support for top-level await

chromium.googlesource.com

21–30 of 310 posts

Re: V8 adds support for top-level await

#21

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…

Isn't every new language doomed to relearn everything in some way?

Re: V8 adds support for top-level await

#22

Earlier quoted context omitted.

Immediately invoked function expression - aka an anonymous function that executes as it is interpreted. (function() { console.log('test'); })(); In old versions of JavaScript, variables had to be scoped to the nearest function (rather than the nearest block) so IIFE where often used for namespacing: var $ = (function() { this.version = '1.2.3'; })(); $.version; // 1.2.3 This worked because the function would be immed…

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'

Re: V8 adds support for top-level await

#26

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

What is an IIFE?

Also, I believe TypeScript uses these to transpile classes with public and private properties/methods (can't verify that's still case atm).

It's a really neat pattern imo, I remember it fondly from my JS heavy days :)

Re: V8 adds support for top-level await

#27

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…

A good editor warns about some of those conditions at least.

Re: V8 adds support for top-level await

#28

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 think JS devs usually use async/await for network calls and not really for computation or file access. Those type of applications are better served by other languages.

A deadlock in the problem space that JavaScript operates in would be a rarity I feel.

Re: V8 adds support for top-level await

#29

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 think JS devs usually use async/await for network calls and not really for computation or file access. Those type of applications are better served by other languages. A deadlock in the problem space that JavaScript operates in would be a rarity I feel.

JS is single-threaded right so (...I think...) deadlocks are actually impossible. Although I guess you can still get stuck if two pieces of code are waiting on each other to satisfy some condition (and trading control of the sole thread) without using explicit locking.

Re: V8 adds support for top-level await

#30

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…

> All this async code without decent locking primitives is leading to a rabbit hole of race conditions...

I haven’t seen this happening. Maybe it’s because I tend to use Node for web apps too much, which don’t have much shared state within Node to begin with? That it’s single-threaded does matter immensely, though, because if you have shared state that can be updated synchronously, you just write the code and know that it runs as a unit.

Post reply on HN