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…
V8 adds support for top-level await
21–30 of 310 posts
Re: V8 adds support for top-level await
#22Earlier 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…
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
#23Now if only python would do the same.
Re: V8 adds support for top-level await
#24Does rust async support this?
Re: V8 adds support for top-level await
#25Re: V8 adds support for top-level await
#26This is huge! Finally no more need to use IIFE's for top level awaits
What is an IIFE?
It's a really neat pattern imo, I remember it fondly from my JS heavy days :)
Re: V8 adds support for top-level await
#27All 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…
Re: V8 adds support for top-level await
#28All 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 deadlock in the problem space that JavaScript operates in would be a rarity I feel.
Re: V8 adds support for top-level await
#29All 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
#30All 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 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.