Hacker News Reader

Comment by whatthejesus | Hacker News Reader

I judge languages by how they look. JavaScript is a wall of const/async/await these days, which is ugly. Functionality aside (the APIs have gotten pretty decent), the language has gotten uglier. It used to be nice and nuanced even with boilerplate. Closures and prototype inheritance is neat. Walls of const are not. Does every enclosed function need a million consts for every expression?

Also, it’s a language where everything happens somewhere else. Not here and now, somewhere else on some other event. That sucks for the small stuff.

View on HN

I am still 95% sure async/await was a mistake.

Async JavaScript using callbacks had a learning curve, but once you learned how to contain it and treat callback indentation as an opportunity to refactor it felt similar to coding in lisp.

The problem was the learning curve, and the fact you had to rewire your brain a bit compared to coding in something procedural.

Yes, I keep saying this. Async await is like loading spinners - a fix for a problem that shouldn't exist in the first place.

As much as possible should be happening locally, synchronously on the computer, in-process, or at least without yielding your thread context (and even then there are things like page faults which async/await wont save you from, they are 'invisible' to a regular developer).

While you might dismiss this idea, page faults used to be THE leading cause of delays back when hard drives were the norm.

That JS supports await isn't nearly as much a problem as the fact that it defensively defers execution any time it encounters one.

This hurts most badly for iterators.

Files are usually read from disks in chunks of 64K bytes. If you present the data as an async byte iterator you'll get 65,534 defensive deferrals, and one actual wait.

If you have ten layers of transformation it will be 655,350 defensive deferrals and 10 real waits.

These defensive deferrals aren't so expensive in terms of CPU time, but they ARE very expensive in terms of wall clock time. All other work must be halted so the event loop code can run. Eventually synthetic deferrals dominate the wall clock cost of running the program. This isn't hypothetical either. Here's someone trying to build steam parsing on Node and finding that it's too slow to be useful: https://github.com/nodejs/node/issues/31979

The solution is stream iterators. They are sync when they can be and async when they must be: https://docs.bablr.org/architecture/spacetime

> it defensively defers execution any time it encounters one

That's a (bad) JS design choice, for example C# doesn't do this. Actually I'm pretty sure even in JS, async/await gets transpiled to state machines, so I think this is easily fixable by shipping a new transpiler implementation that only defers when necessary.

I get your point, but I don't think we should go back to oldschool yield-based iterators to hack around a broken implementation.

Yeah it's fixable. Everything I've built is built on top of a Symbol.streamIterator protocol that omits the unnecessary deferrals. The code looks like this: https://github.com/bablr-lang/node-fs/blob/6dabc6916082eb09c...

I would like to see official support for `Symbol.streamIterator` and for the `for await?(item of iter)` syntax which would transpile to code like you see here (or all the way down to regenerator state machines if needed).

just because a keyword makes shitty devs shoot themselves in the foot, you shouldn't remove the keyword

I'm still sour why goto doesn't exist in javascript

It's limited to looping but there is a shockingly similar concept in the label statement that few seem to know about (for good reason): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I mean everyone should know labels if you have to break inside a nested loops. At least I hope so cause then that code has some bad bugs in it.

Reply on news.ycombinator.com