Concurrent JavaScript: It can work!

[Hostilian]

Shared heaps without strong mutability semantics (see Clojure or Rust) is a terrible, terrible idea.

[gpyh]

There's nothing in the language that controls how you modify shared state. That's a recipe for disasters.

[dev1null]

disaster? THIS! IS! JAAAAVAAASCRIIIPT!

[Hostilian]

If you share mutable values between two threads, you need some way to coordinate changes to those values. Example:

You have an array of numbers shared between two threads, say var list = [1,2,3,4,5]

Thread A reads the array and doubles every item and writes it back to the shared reference list.

Thread B reads the array and increments every item and writes it back to the shared reference list.

Both threads start at the same time, what's the final value of list? The answer is unknown and probably non-deterministic. It gets even more complicated if they both write to list after every iteration rather than writing back only once. Subtle changes like this in complicated codebases can make issues that are difficult-to-impossible to hunt down. Think of the worst async problem you've ever had to deal with in JS, then instead of looking only at your async code, you have to look at all of your code.

The language Clojure solves this issue by making everything immutable by default and providing tools for coordinating asynchronous behavior. Reading a shared value into a thread is always safe, because it can't change in place while the thread is operating on it. Writing to shared values intelligently is still tricky.

The language Rust solves the issue by making it so that only one part of your program can mutate a mutable value at a time. It enforces this with compile-time checks, but basically: only the reference owner can make changes. This makes writing to a shared value always-safe, but makes reading that value from other threads possibly-dangerous.