Proposal of Multithread JavaScript

Michael J. Ryan tracker1 at
Wed Nov 2 15:38:14 UTC 2016

Sorry for reply...

var a = {};
Thread 1: Object.assign(a, {...});
Thread 2: Object.assign(a, {...});

So many places to blow up internally it isn't funny... Also, as I said,
even where threading is first class with locking, there are really weird
bugs when people who don't intimately understand things write code...

Having a clear worker pattern is safer...  Adding internalized immutables
to improve message passing would be nice, as would an rpc to promise

Real threads however is a truly bad idea in JS...

On Nov 2, 2016 8:31 AM, "Michael J. Ryan" <tracker1 at> wrote:

There is a difference between thread safety and unexpected event ordering
in a higher level language..  just because you don't think of it in the
language doesn't mean it isn't there... Also the js environments are multi
threaded, it's just those threads are for internals and abstracted away
from you in a safe way.

On Nov 2, 2016 8:26 AM, "Leo Dutra" < at> wrote:

> Is not a matter of being faster. Is a matter of using machine potential
> and using better internal instructions.
> JavaScript sits over libuv and engines with multithreading without using
> multithreading.
> And about being faster, any serious language has a simple feature like
> threads and Visual Basic should not emerge even in Microsoft specs
> discussions. What comes next? PHP?
> I still don't understand why you talk so much about racing conditions in a
> language which one of the main aspects is loose clojuring and racing
> condition.
> Who cares about thread-safety if it were never expected and if it all can
> be seamless. And where it would not be explicit?
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list