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

41–50 of 310 posts

Re: V8 adds support for top-level await

#41

Post by foota »

jdm2212 wrote: post #29
drevil-v2 wrote: post #28

Earlier quoted context omitted.

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.

Yeah, nothing about JavaScript being single threaded implies any resistance to deadlock.

Re: V8 adds support for top-level await

#43

Post by TimTheTinker »

megous wrote: post #9
miguelmota wrote: post #2

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?

For some use cases, the difference can be a little more dramatic.

    fetch(allResourcesUrl).then(async response => {
      let allResources = await response.json();
      let pageResource = await (await fetch(allResources.page1.url)).json();

      // set up page with pageResource
    });
can be replaced with

    {
      let allResources = await (await fetch(allResourcesUrl)).json());
      let pageResource = await (await fetch(allResources.page1.url)).json();

      //set up page with pageResource
    }
Note use of a top-level block instead of a function context to hide local variables.

Re: V8 adds support for top-level await

#45

Post by elyobo »

TimTheTinker wrote: post #43
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?

For some use cases, the difference can be a little more dramatic. fetch(allResourcesUrl).then(async response => { let allResources = await response.json(); let pageResource = await (await fetch(allResources.page1.url)).json(); // set up page with pageResource }); can be replaced with { let allResources = await (await fetch(allResourcesUrl)).json()); let pageResource = await (await fetch(allResources.page1.url)).json(…

What's with the `let` though?

Re: V8 adds support for top-level await

#46

Post by elyobo »

james-mcelwain wrote: post #35
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?

Or my preferred (gross) version: void async function main() { // code }()

Mine all tend to look like

  (async () => {
    // code
  })().catch(console.error)

Re: V8 adds support for top-level await

#47

Post by jraph »

james-mcelwain wrote: post #35
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?

Or my preferred (gross) version: void async function main() { // code }()

Wow, I had completely forgotten the existence of void in JavaScript.

Why is it needed here? To force an expression without using the parentheses?

Edit: Yes, it seems so, and this usage with functions is explicitly documented there: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: V8 adds support for top-level await

#48

Post by _bxg1 »

londons_explore wrote: post #19

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…

Data races are impossible in JavaScript because it's single-threaded. Race conditions are possible in any language that can do anything asynchronous, which is basically all of them. But the general benefit you get from JS being single-threaded is the fact that any given callback is transactional. No other code will ever come in and mutate state between two regular lines of JavaScript code. Achieving this is pretty much the whole point of locking mechanisms, so under normal circumstances they aren't necessary for JS.

That said, when you use async/await instead of promises or callbacks, things do change because two sequential lines of code are no longer two truly sequential instructions. You're muddying the most fundamental metaphor of code syntax. That's why I personally don't like async/await syntax, although I get why people want it.

Re: V8 adds support for top-level await

#49

Post by pseudoramble »

londons_explore wrote: post #19

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…

> 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.

Can you elaborate a bit more on this? I'm unsure about how locking in a single-threaded environment would work. And how would it really differ from async/await or promises which can handle race conditions already?

One area where the lack-of locking primitives does worry me is the use of shared mutable memory. I've never used these techniques in JS, but if I remember right one can now do something like this:

1. Create a shared memory array

2. Spawn several workers which do work on shared arrays

3. Pass a reference to the array to each worker and let them run.

This seems like an area where we could start to see these problems start appearing. There's a module related to atomic operations [1] but there is no language-level enforcement of using it. There could be good reasons why this isn't worrying but I just don't happen to know that off hand.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: V8 adds support for top-level await

#50

Post by trust07007707 »

pseudoramble wrote: post #49
londons_explore wrote: post #19

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…

> 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. Can you elaborate a bit more on this? I'm unsure about how locking in a single-threaded environment would work. And how would it really differ from async/await or promises which can handle race conditions already? One area where the lack-of locki…

There is an Atomics API for that...
Post reply on HN