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

131–140 of 310 posts

Re: V8 adds support for top-level await

#131

Post by eropple »

manigandham wrote: post #99
eropple wrote: post #63

Earlier quoted context omitted.

There are more and more valuable locking mechanisms than a bool. Read-write locks, for example, are still sometimes (not often but I've done it on occasion) valuable in NodeJS.

Only the single JS thread is ever reading or writing a value so what is the lock for?

You get that it's super common to await in the middle of something that could be considered a critical section, yeah? And that doing so will result in a different coroutine (for lack of a better term; that's what Promise-driven code effectively is) being executed until control returns to the awaited Promise within that critical section?

Re: V8 adds support for top-level await

#132

Post by jeswin »

vidarh wrote: post #114
hombre_fatal wrote: post #80

Earlier quoted context omitted.

I don't think it really makes sense to essentially say "Javascript is rife with race conditions like any other language" just because yes, you still need to use transactions when using a database.

You're reading too much into the example. Your 'database' can be your frontend js state. There is nothing in the example that limits the problem to backend development.

Yeah but the impact of race conditions on front-end code (which is always single user) is minimal; unlike the backend where it's catastrophic and not fixable by refreshing the page.

Re: V8 adds support for top-level await

#133

Post by hombre_fatal »

Arelius wrote: post #115
PetahNZ wrote: post #70

Earlier quoted context omitted.

One use case I often find is a caching layer between JS and a HTTP call. If there are 2 calls to a non cached endpoint, the HTTP will fire off twice before caching the result. You can work around this by returning the first promise from the cache, but this is essentially a mutex. Having locking primitives would solve this and require less boilerplate code.

Do you really want to block all of your http calls on the result of the prior call in the off-chance that they might share a result just so you can only cache the results and not the promises? The reason we don't have a mutex in javascript is that there are better solutions to the problems it solves.

Maybe I don't understand your response, but a map of promises to handle parallel in-flight requests for the same resource (which the grandparent pitched) is basically the most elegant yet simple solution to this common problem.

I don't really see how it's a mutex though, you're just returning the same promise to multiple requests. It's far simpler and doesn't use a locking construct.

Re: V8 adds support for top-level await

#134

Post by dboreham »

tudorconstantin wrote: post #126
_bxg1 wrote: post #48

Earlier quoted context omitted.

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…

Since an async function is simply a function that returns a promise is there actually any difference between using async/await and using promises explicitly?

It takes longer to boil your brain.

Re: V8 adds support for top-level await

#135

Post by jnbiche »

kbenson wrote: post #111
jnbiche wrote: post #101

Earlier quoted context omitted.

Javascript devs, for all their flaws, understand async programming far, far better than the average C programmer. Indeed, your assertion that we need "locking primitives" to counteract "race conditions" is evidence of that. Yes, JavaScript can have race conditions, but not multi-threaded race conditions that cause resource contention [0]. So what good would locking primitives be? And as a solution to single-threaded…

> also ignorant, because 1990s C was decidedly synchronous There was definitely threading in C in the 1990's, and threads are asynchronous by nature. There's a whole class of synchronization bugs that C and C++ developers had to learn to deal with, and while JavaScript developers get to avoid some by the nature of there being a single thread, that doesn't necessarily exempt them from all of them.

Threading implementation was async, not the programming model. Async programming style/model(as far as I'm aware) refers to the use of callbacks or coroutines, neither of which was common at all in C in the 1990s.

Indeed, nginx caused big waves due to its superior IO performance as the first popular async http server released in 2004.

But correct me if you have a different understanding of the term.

Re: V8 adds support for top-level await

#136

Post by hombre_fatal »

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"?

Synchronous code blocks the event loop, so in real world code you'd only use the sync-version in some special cases, like when you're reading config files before you "server.boot()" and other scenarios where it's just a one-time cost.

Though the few sync functions in the stdlib become less and less convenient, first when promises came out, then with async/await, and now with top-level await.

Re: V8 adds support for top-level await

#137

Post by Zarel »

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?

If all you're doing on catch is forwarding to `console.error`, you could just write:

    // code
Outputting errors to console is the default behavior.

Re: V8 adds support for top-level await

#138

Post by dboreham »

jnbiche wrote: post #122
vore wrote: post #119

Earlier quoted context omitted.

How will you update the bank account with an immutable data structure? You need to mutate the balance somewhere.

Well, in practice you're presumably using a database, which has transactions in the API you're using. But to answer your question, in functional programming (also frequently ReactJS, if you use libraries like Redux), you don't mutate the data structure. You create a new data structure based off the old one. Am I misunderstanding your question? Just because you use an immutable data structure doesn't mean it can't be…

Database written in not(Javascript) of course, since it has to work and handle concurrency properly.

Re: V8 adds support for top-level await

#139

Post by Zarel »

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

No, while this is sometimes used for private properties/methods, TypeScript never used it. TypeScript's private properties/methods are just compile-time errors, they're still public in the generated code.

Re: V8 adds support for top-level await

#140

Post by manigandham »

eropple wrote: post #131
manigandham wrote: post #99

Earlier quoted context omitted.

Only the single JS thread is ever reading or writing a value so what is the lock for?

You get that it's super common to await in the middle of something that could be considered a critical section, yeah? And that doing so will result in a different coroutine (for lack of a better term; that's what Promise-driven code effectively is) being executed until control returns to the awaited Promise within that critical section?

Yes but async/await is for concurrency, not parallelism. Only one or the other "coroutine" will run at any time so what is the lock protecting? There's no way for multiple branches of code to access the same variable at the same time in JS. What else would a reader/writer lock be used for?
Post reply on HN