Proposal of Multithread JavaScript

Florian Bösch pyalot at
Wed Nov 2 15:11:29 UTC 2016

What I meant to illustrate is that concurrency always leads to race
conditions, and that neither promises nor async/await are free of them, and
so it's silly to argue against co-routines on that basis, because of all
the continuation mechanisms, they're the most convenient to use with the
least drawbacks (no infectiveness).

On Wed, Nov 2, 2016 at 4:08 PM, Leo Dutra < at> wrote:

> Bösch, this is the legacy of callbacks.
> ECMA does a great job with specs, but JS does every step to solve the last
> step.
> Callback became a promise for modularity. Promise is hidden in async await
> for simplicity. Common constructs, but in JS they came in being adapted for
> JS world.
> As I said, immutability is not strong in JS as it is not a PURE functional
> programming language.
> Weird or not, this led us to the possibility of multithreading with total
> share and mutability.
> If we wanna multithread in here, we have to respect all the JavaScript
> legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT
> As said in my first argumentation, we have race condition problems and
> total share of scope and none died because of it. Multithread can be used
> to run these callbacks, functions and promises seamlessly and if we want it
> different... that's a huge bad conversation about foundations of JavaScript
> and a total change that would wreck the JS world and let us to anything
> that is not JS.
> We have to decide if we stick with scope sharing and mutability or look
> for another language. JS is what it is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list