Fork needs to evolve a bit for capability-based security, but other than that fork is ok. The problem is in concurrent shared memory access, which is extremely hard to get right. And the fix is to deprecate shared memory multithreading altogether. It's too hard to use, too slow, too broken and has no future either way.
> And the fix is to deprecate shared memory multithreading altogether.
Not gonna happen without a radically different CPU, OS, and application software paradigm. In other words: extremely unlikely in the next 2-3 decades (at least).
> It's too hard to use
Agree for most languages. Have you tried Rust? It makes shared memory multi-threading not just much simpler, but also safe.
> too slow
Very wrong for multi-core CPUs, where message-passing is emulated using shared memory.
> too broken
What does that even mean? With the right language-enforced mechanism, it is very much non-broken and functional.
That is simply wrong. Rust makes it easy and safe to share immutable data – it's the ability to mutate that can't be shared.
> data is owned explicitly and passed explicitly
Yes, data is owned explicitly, but the permission to read or write the data is somewhat independent of ownership – the owner of an object can grant permission to access the object, and it can pass this permission to other threads without relinquishing ownership.
> it's the ability to mutate that can't be shared.
So, I do think you're more right than your parent, but I also think this formulation misses important things.
Rust only lets you share when you cannot cause a data race. A type like Mutex lets you share something that's mutable, because the mutex is guarding the sharing. Functions like split_at_mut let you mutably share disjoint parts of a slice.
