Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too.

Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.

I don't think it is a good idea to stray away from the bare metal in this case. We're trying to bootstrap other languages on top of JS. They can introduce their own abstractions to shield off the programmer. Just my 2ct.

JS already supports immutable objects, by using Object.freeze().

That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).

Right, that's where libraries like ImmutableJS come in.

That's not deeply immutable like you'd want for sharing objects across threads, or even for using in contexts like React and Redux.

Not too hard to call Object.freeze() recursively to get the deep immutability you need. And of course there's ImmutableJS for other immutable data structures.

Shared memory could be hidden from the users. Passing objects would really be passing control of objects. If process A creates object a, and passes it to process B, no copying has to happen if the underlying mechanism uses shared memory and access control to effect the transfer (a change of owner).

Yes. Presumably transferrable objects would have to be created on a shared heap. Non-transferrables would live on thread-local heaps.

I find that thinking about multiple heaps is harder than thinking about threads. (Ever programmed with scoped memory? It's a nightmare.)

I find that thinking about transferrables is harder than thinking about threads. It's gross that an object suddenly loses all of its state just to give that object to another thread. Then, other parts of your code that still want access to that data have to do things that are definitely more gross than acquiring a lock.

You don't need locks to access immutable objects (except perhaps for garbage collection).

But I agree that transferring control is a bad idea.