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

81–90 of 310 posts

Re: V8 adds support for top-level await

#81

Post by ihuman »

_bxg1 wrote: post #48
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 mu…

> 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

I thought async/await was just syntactic sugar for promises?

Re: V8 adds support for top-level await

#82

Post by drevil-v2 »

ChristianBundy wrote: post #68
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.

I've been using async/await especially for file access. const fs = require('fs').promises const path = require('path') const filePath = path.join(__dirname, 'package.json') const fileContents = await fs.readFile(filePath, 'utf8') console.log(fileContents)

Well I personally would use a synchronous method rather than async for something like that where the next code path depends on the return data; if you can't get the file contents then you want to throw an error straight away.

Re: V8 adds support for top-level await

#83

Post by Scooty »

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?

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.

Re: V8 adds support for top-level await

#84

Post by pitaj »

dlbucci wrote: post #75
pitaj wrote: post #25

Earlier quoted context omitted.

JS async is implemented as generators as well AFAIK

Not unless promises are implemented with generators. I dunno though, I feel like there's some overlap between the two concepts, so maybe they are?

Promises are just objects which represent an asynchronous value.

Async/await are coroutines: they have a shared context, stack, etc. They can be paused and resumed.

The implementation of async/await depends on the engine, but I'm pretty sure they use the same generator backend.

Babel and other transpilers convert async functions actual generator functions. By contrast, promises are a fairly simple runtime library.

Re: V8 adds support for top-level await

#85

Post by ihuman »

ChristianBundy wrote: post #68
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.

I've been using async/await especially for file access. const fs = require('fs').promises const path = require('path') const filePath = path.join(__dirname, 'package.json') const fileContents = await fs.readFile(filePath, 'utf8') console.log(fileContents)

Is there an advantage to using "await fs.readFile" over "fs.readFileSync"?

Re: V8 adds support for top-level await

#86

Post by Scooty »

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…

Making await implicit would make it difficult to manage parallel promises. You would either have to make an exception for Promise.all or add new syntax. It's also not unheard of to have hanging promises (fire and forget).

Types make it easier to catch mistakes early in general. Typescript has a compiler rule 'no-hanging-promises' to help avoid forgetting to await.

Re: V8 adds support for top-level await

#87

Post by mayank »

ihuman wrote: post #85
ChristianBundy wrote: post #68

Earlier quoted context omitted.

I've been using async/await especially for file access. const fs = require('fs').promises const path = require('path') const filePath = path.join(__dirname, 'package.json') const fileContents = await fs.readFile(filePath, 'utf8') console.log(fileContents)

Is there an advantage to using "await fs.readFile" over "fs.readFileSync"?

You haven't blocked the entire event loop (i.e., other async functions that may be waiting on I/O) while the file is being read.

Re: V8 adds support for top-level await

#88

Post by Scooty »

pitaj wrote: post #25
iikoolpp wrote: post #23

Earlier quoted context omitted.

Impossible due to how async is implemented (as generators).

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.

Re: V8 adds support for top-level await

#89

Post by munchbunny »

alexanderdmitri wrote: post #26
danappelxx wrote: post #3

Earlier quoted context omitted.

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 :)

It's a useful pattern that I used a lot, though I don't know if I would agree that it's neat. I definitely prefer the explicit annotations or even the python underscore convention.

Re: V8 adds support for top-level await

#90

Post by earthboundkid »

aledalgrande wrote: post #71
joshAg wrote: post #55

Earlier quoted context omitted.

let plus the curly bracket scoping means that the variables only exist within the curly brackets, and not the global state.

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.
Post reply on HN