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

241–250 of 310 posts

Re: V8 adds support for top-level await

#241

Post by megous »

earthboundkid wrote: post #90
aledalgrande wrote: post #71

Earlier quoted context omitted.

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.

I'm with you. Though typing `if (a = 1) {}` happens to me sometimes, and const may catch this earlier. I don't use a linter anymore, but I suppose any serious linter would warn about assignement in a condition, anyway.

Re: V8 adds support for top-level await

#244

Post by [deleted] »

tanr54ok wrote: post #229
jnbiche wrote: post #135

Earlier quoted context omitted.

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.

Your post manages to say nothing correct. Javascript did not invent callbacks, asynchronous programming, or event driven programming. Nodejs popularized it in the 2010s but you are claiming credit for something that has been in common use since the 70s. I have no clue how anyone can speak with such authority while clearly having not done a cursory glance at programming APIs available in the 80s and 90s. Lighttpd was…

[deleted]

Re: V8 adds support for top-level await

#245

Post by braythwayt »

nickitolas wrote: post #242
bandrami wrote: post #235

So COMEFROM is now a first-class feature of the most popular programming language in the world. Intercal really was ahead of its time.

Could you elaborate?

COMEFROM began as a joke comtrol-flow construct, but the principle turns out to have a deep semantic value:

https://en.wikipedia.org/wiki/COMEFROM

Aspect-Oriented Programming is a kind of COMEFROM. The proposition in the comment is that await is another.

Re: V8 adds support for top-level await

#246

Post by olalonde »

robert_tweed wrote: post #230
olalonde wrote: post #184

Earlier quoted context omitted.

There's an important difference: the process will crash if you don't catch the error.

While this is 100% correct, if the main function has returned then the process was going to end anyway (assuming there isn't additional code after the call to main). If there's a main loop, then the catch needs to be inside that loop, not outside of main. The only difference it will make here is to suppress the default stack trace[1] and errorlevel returned to the shell. If you are writing in this kind of "scripting"…

> While this is 100% correct, if the main function has returned then the process was going to end anyway (assuming there isn't additional code after the call to main).

That's not necessarily the case (or maybe poorly worded), e.g.:

    async function main() {
      // code
      setInterval(() => console.log('hey'), 1000)
    }
    main()
In real life, it would probably be a HTTP server holding up the process. It's true that you likely want to crash hard if you have unhandled error during server initialization but I would still catch the error because Node.js will otherwise print a bunch of ugly "UnhandledPromiseRejectionWarning" messages. E.g.:

    main().catch(err => {
      console.error(err);
      process.exit(1);
    });
With top level async landing in v8, I guess Node.js will eventually stop printing those warning messages.

Re: V8 adds support for top-level await

#247

Post by zo1 »

jnbiche wrote: post #101
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…

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…

> "Javascript devs, for all their flaws, understand async programming far, far better than the average C programmer."

Not the junior ones, they don't. I understand the need to want to talk about this advanced topic with only perfect and good developers, but this is almost never the case in concrete scenarios. Developers forget, developers share code with other developers and the consequent spaghetti mess is hard to reason about 100%, developers make mistakes, developers are sometimes yet to learn something, developers miss small bugs, new code deals with library code that might have an async bug, etc.

Sequential flow is much easier to reason about and control for, and if you ask for my opinion, we should only use async features if the benefits of their usage far outweigh the potential complexity and headache that they introduce if you don't "use them the right way".

Re: V8 adds support for top-level await

#248

Post by zo1 »

jnbiche wrote: post #143
dboreham wrote: post #138

Earlier quoted context omitted.

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

Yes, of course. Why would you build a database in JS? And does gmail not work well for you? Most of us are only using JavaScript because that's the only way to build browser applications (or compile-to-JS languages, which still require an understanding of JS or you'll run into problems). In any case, I don't particularly like JS, so your dig fell short. But JS is necessary for many of us.

> "Most of us are only using JavaScript because that's the only way to build browser applications (or compile-to-JS languages, which still require an understanding of JS or you'll run into problems)."

The javascript apocalypse is inevitable, we're just yet to reach the tipping point where this hard-requirement to use JS for web/browser applications is no longer there.

Re: V8 adds support for top-level await

#249

Post by nemetroid »

matt-attack wrote: post #150
ihuman wrote: post #129

Earlier quoted context omitted.

Are you sure? From what I can find, async [0] causes a function to a return a promise, which then returns the result. Await [1] takes a promise, and waits for it to either be resolved or rejected. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> and waits for it Yes but that doesn’t mean other lines of code can’t be executing while waiting. The waiting isn’t truly blocking the entire application. Plenty of other things can be happening.

Sure, but the next line of the function awaiting the result can't execute while waiting.
Post reply on HN