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

291–300 of 310 posts

Re: V8 adds support for top-level await

#291

Post by random314 »

jnbiche wrote: post #146
vore wrote: post #107

Earlier quoted context omitted.

Just because code is written in an asynchronous style doesn't prevent correctness errors that would not exist with locking. For instance, using everyone's favorite example, a bank: In no particular order: 1. Pizza company debits by balance by $5 2. I withdraw $5 Assuming both those operations can yield due to e.g. async requests and that they can be resumed at any point, I don't know which order they will yield or re…

> With regards to resource contention, anything that causes a waiter graph cycle can cause deadlocking Maybe I'll learn something here, but can you explain how an async runtime with no locking primitives like JS could cause a waiter graph cycle?

You don't need locking primitives for a deadlock. Await is sufficient.

Re: V8 adds support for top-level await

#292

Post by wayneftw »

nitely wrote: post #277
wayneftw wrote: post #259

Earlier quoted context omitted.

Both of your statements are incorrect. Locks are an abstract concept that have many different behaviors. In a multi-threaded world (not JS) a certain type of synchronization lock, such as a single-writer/multiple-reader locking mechanism would specifically allow you to unblock all waiting coroutines. Another type of lock might only allow the first waiter to unblock. There simply is no concurrency in JS though, so the…

First look up the definition of a lock and mutual exclusion. There are two types of basic locks: mutexes and semaphores. Both keep two threads or coroutines from executing a block of code/instructions at the same time, and both work in a similar way I already described. > There simply is no concurrency in JS though, There is no parallelism in JS (well there is with workers now), concurrency is not parallelism.

Show me a piece of code where you think you need locks I guess.

I will concede that I got the two terms confused, mostly because I haven’t had to think about this kind of stuff in years because there’s literally nothing I’ve ever had to do with JavaScript that’s required me to think about it.

But I’d really love to see some code where you can’t handle concurrently waiting coroutine priorities in a single threaded world. Concurrency without parallelism is not really a problem the way I see it.

Re: V8 adds support for top-level await

#293

Post by paulsutter »

jnbiche wrote: post #278
paulsutter wrote: post #253

Earlier quoted context omitted.

> 1990s C was decidedly synchronous You know that Javascript is a C(++) program? That when you use TCP, the protocol is in C? The ethernet driver is written in C? The OS scheduler is written in C? That you're programming in a little sandbox, and all the concurrency around you in managed in C? There has never been anything synchronous about C.

> You know that Javascript is a C(++) program? JavaScript is not implementation-defined. There's a spec, and there are interpreters in a number of different languages. Sure, most common JS interpreters/JIT and otherwise, are in C++, but that says nothing about whether or not they use an event-driven style underneath to program the interpreter. And regarding C being synchronous, I'm talking about programming models, n…

No matter what language you are using, concurrency happens in instructions, interrupts, cores, caches, devices, virtual memory mechanisms, etc, not even getting into GPU architecture. In C you have direct control over these things, you can make the system as concurrent as you want.

In Javascript you have a little window into this through whatever the layer below provided you. So Javascript by definition has a (small) subset of the concurrency you can get in a systems language.

And no I'm not entirely sure what you're talking about. It sounds like you learned concurrency in Javascript, and define concurrency in terms of Javascript primitives. But that's merely a guess on my part.

Re: V8 adds support for top-level await

#294

Post by earthboundkid »

root_axis wrote: post #220
earthboundkid wrote: post #90

Earlier quoted context omitted.

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.

The const keyword has absolutely nothing to do with state mutability, that is a misconception. const in es6 is a keyword meant to explicitly prohibit identifier reassignment and it does indeed reduce bugs because it communicates developer intention regarding how a variable reference is expected to behave in a section of code. Further, use of const by default is a best practice because it leaves less room for error in…

My whole argument was premised on const not having anything to do with mutability.

Re: V8 adds support for top-level await

#295

Post by earthboundkid »

aledalgrande wrote: post #145
earthboundkid wrote: post #90

Earlier quoted context omitted.

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.

By waste of time do you mean performance or coding time? I feel like writing a character more is not a waste of time, if you are just following the convention that anything that is not going to be muted should be signed explicitly. It's not to prevent bugs, but for readability and ease of use.

Time deciding if you can/should rebind a variable or not is a waste of developer time.

Re: V8 adds support for top-level await

#296

Post by elyobo »

earthboundkid wrote: post #295
aledalgrande wrote: post #145

Earlier quoted context omitted.

By waste of time do you mean performance or coding time? I feel like writing a character more is not a waste of time, if you are just following the convention that anything that is not going to be muted should be signed explicitly. It's not to prevent bugs, but for readability and ease of use.

Time deciding if you can/should rebind a variable or not is a waste of developer time.

I sort of agree; I solve this by never using let and never rebinding :) No need to think about it at all.

Re: V8 adds support for top-level await

#297

Post by bzbarsky »

bandrami wrote: post #283
bzbarsky wrote: post #272

Earlier quoted context omitted.

I'm not sure I quite see the analogy to COMEFROM. The "problem" with COMEFROM is that at the "target" location (the one control comes from) there is no in-source indication of the control flow transfer. So what looks like linear code turns out to have this unexpected detour to the location of the COMEFROM instruction. This hinders understandability of the code. "await" in JS doesn't have that problem: there is an exp…

> I guess the concern is that you could have linear code that calls a function, which does an "await" and you would effectively have a control flow detour that's hidden from view? That's the main issue. The overall control flow cannot be known until the entire abstract syntax tree is generated.

To be fair, that's a problem with GOTO as well (which JS doesn't have, yes); you don't have to go all the way to COMEFROM to get that....

That said, with JS you can't know the overall control flow even one you have the AST, because that `foo()` function call could go anywhere depending on what people did to the global scope independently of your AST.

Come to think of it, you can't even determine control flow from the AST in C, unless everything involved has static linkage...

Re: V8 adds support for top-level await

#298

Post by aledalgrande »

earthboundkid wrote: post #295
aledalgrande wrote: post #145

Earlier quoted context omitted.

By waste of time do you mean performance or coding time? I feel like writing a character more is not a waste of time, if you are just following the convention that anything that is not going to be muted should be signed explicitly. It's not to prevent bugs, but for readability and ease of use.

Time deciding if you can/should rebind a variable or not is a waste of developer time.

Then when you will have to change or debug the same code instead of writing new, you will have to spend more time understanding what variable is the source of a state change, for example inside a loop. That is more of a waste of time to me.

Re: V8 adds support for top-level await

#299

Post by anonytrary »

mstade wrote: post #237
anonytrary wrote: post #159

Earlier quoted context omitted.

The function is both synchronous and asynchronous until it is called by the caller. This is called Shannon's Cat. Jokes aside, I'd like to add that just because a function returns a promise doesn't mean the caller will always want to wait for it to resolve. I think of `await` as a simple modifier that casts the return value from a `Promise ` into `T`. By getting rid of the modifier, we can no longer assume that the c…

You're right of course, and I have zero data to back this up other than anecdotes from my own experience, but still I posit the most common case is that the caller wants to await the return value, not run the function asynchronously. This is why I think it'd make more sense to flip the semantics so you'd have implicit await, and have to explicitly mark the things you want to run asynchronously.

I think there might be some confusion here. `foo()` will run asynchronously regardless of whether or not `await` is specified. I agree that in most cases, you will want to unbox the Promise. It is still very common to pass Promises around as values.

Re: V8 adds support for top-level await

#300

Post by alexanderdmitri »

Zarel wrote: post #139
alexanderdmitri wrote: post #26

Earlier quoted context omitted.

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.

You're right[0], which is weird because they got most of the way there. I guess I just assumed since they were leveraging IIFEs this would be a natural use case. I'd be interested in knowing why they didn't actually.

According to this[1] exchange on Stack Overflow, the IIFE is used by TypeScript because of other scoping issues (specifically protecting class properties before instantiation and defining interfaces).

[0] https://yakovfain.com/2015/06/30/the-private-in-typescript-i...

[1] https://stackoverflow.com/questions/56086411/why-does-typesc...

Post reply on HN