> Erlang only shares large binaries between processes to ensure process heaps and thus garbage collections are completely independent.
That sounds unnecessarily restrictive. At least they should give developers a choice (e.g., "this process should receive integral data, and should not be disturbed by a GC cycle of other processes").
Also, concurrent (not stop-the-world) GC techniques could make this problem moot.
> Also, concurrent (not stop-the-world) GC techniques could make this problem moot.
It would mostly introduce insane additional complexity. Erlang GC works per-process (each process has its own private heap and stack) and you'd normally create lots of small processes, so the GC is concurrent as an emergent effect of the system construction.
Not to mention processes can be distributed across nodes for which your scheme completely breaks down, what's supposed to happen if you ask for memory sharing across the network?
> It would mostly introduce insane additional complexity.
GoLang has a concurrent garbage collector.
> what's supposed to happen if you ask for memory sharing across the network
Yeap, I mentioned that. Again, as a developer you want the choice. You don't want your language telling you "sorry, that's too complicated for your brain, so you can't do that".
That sounds unnecessarily restrictive. At least they should give developers a choice (e.g., "this process should receive integral data, and should not be disturbed by a GC cycle of other processes").
Also, concurrent (not stop-the-world) GC techniques could make this problem moot.