Hacker News Reader

Comment by kragen | Hacker News Reader

The reason explicit asynchrony produces more reliable software than implicit cooperative threading like Lua coroutines is explained at book length in the doctoral dissertation of Mark S. Miller: http://www.erights.org/talks/thesis/markm-thesis.pdf

He is one of the main participants in the ECMAScript committee.

If you disagree with his arguments, please explain why. But you don't seem to have heard of them in the first place, simply assuming that the reason JS isn't designed the way you would have designed it is because the designers weren’t as smart as you are, explaining their choice as “someone finds it tedious to split their 300 C calls to few continuation callbacks.” Sometimes people will disagree with you for reasons other than being stupid or lazy.

View on HN

Would you be willing to explain why explicit asynchrony is superior to implicit cooperative threading? Rather than simply engaging in more namecalling.

Mutable state is always a problem, but it's a bigger problem when there are less constraints on when it can mutate. But Mark's dissertation explains this and some related issues a lot better.

Also, I don't think I did any name-calling?

That isn't a "normative" statement about better, but a "positive" statement about a trade-off of expressive power versus rigor. A bit of mathematical intuition suggests that formally asynchronous approaches tend to be less powerful and hence more rigorous. But if your spec is still in the prototype phase, taking on a lot of expressiveness and permission with respect to your domain model is desirable because it gets you an end-to-end solution sooner.

What is good is not "on time" or "robust", but "on time and robust". Necessary and sufficients.

Yeah, that's why I said “produces more reliable software” rather than “is better”. In this case what you're buying with the flakiness is more a matter of performance than of expressiveness, but everything is intertwingled.

>Mutable state is always a problem, but it's a bigger problem when there are less constraints on when it can mutate.

A very long-time project I’m idly working on with my life-long colleague addresses this issue. It is real, as are all race conditions and threading issues. But it doesn’t have to be solved at the language level.

One of solutions we proposed to ourselves was that an object storage should manage shared access conflicts. You may see it in Redux and other stores that serve a “frontend framework backend layer” duty today. Even with explicit async, you will always have some high-level races that must be dealt with. And these do exactly that.

The basic idea is that local state is strictly local and not a subject of parallel mutation, and shared state is shared via internally locking/serializing controller who knows better how to mutate, merge or throw. It doesn’t push the problem down the code or execution model, since it’s what’s it for.

Sounds like you'd benefit from reading Mark's dissertation. Not that he solved the problem but he did try a lot of candidate approaches, discuss them with others, and comprehensively review the existing literature; and he reports on several years of trying things similar to what you're thinking of.

I’m not going to read this 229-page doctoral dissertation book for two reasons.

First, it is too long to be practical. Please don’t push the doctoral things on me, we all know that 99.(9)% of what we do in js is not a rocket science. If you want me to feel stupid before someone more educated, fine, I’m okay with that. But even if that’s true, people love to experiment and find their best ways to do something. Also it’s not me who implemented coroutines in Lua this way, it’s PUC Rio guys who made it looking at Scheme. I trust them better than a committee that required 30(?) years to make something bearable without transpilation from the future and hundreds of polyfills.

Second, I’ve asked this question before, and it was browser guys who said that they are not willing to do that, because the legacy is real. And webassembly will not support that neither, because it works in a browser and should obey its rules. Whatever that dissertation concluded, it is committee+browser decision to strip all possible source languages from having such coroutines when targeted at webassembly. It is simply not fair, freedom restricting and has nothing to do with someones educated opinion.

JS is designed in part based on lessons learned from the mistakes of past languages.

Scheme doesn't have coroutines as such; it has first-class continuations.

You can definitely implement cooperative threading in a compiler whose target language doesn't have any kind of threads. You know the 386, SPARC, and PDP-11 don't have threading? It's all simulated. (Wasm probably will have first-class shared-memory threads though. It's being trialed in Chrome already.)

>You can definitely implement cooperative threading in a compiler whose target language doesn't have any kind of threads

I can’t find that thread in my comment history, but there was a wasm guy who basically said nope, not gonna have it, loud and clear, exactly in the context you noted. If that was not true, and all browser vendors will allow it, good.

You can just compile to explicit CPS or equivalent.

Reply on news.ycombinator.com