Erlang has micro-heaps, each process has its own heap so GC pause times are minuscule. Having too much address space is a liability, so limiting the reach of piece of code has GC advantages. I think as memory limits increase we will move to something like tagged heaps, a melding of GC, memory regions and static allocation. One can already get this by running multiple emscripten compiled programs in a JS engine, esp if one pushes tasks into web workers.
You don't necessarily have to serialize data between services if one uses something like capnproto or flat buffers.
That kind of architecture might be ok for problems but I not sure how general it is. Also, why force a diffrent programming model when it is possible to have a GC that does a good job.
There is erlang on java and it performs quite well, so you can combine the two things.
I dont want technogoly to force my architecture, if I make a choice to go with actors I want it to be, because its the right choice and not because I have to.
Having a global flat address space has its tradeoffs. We use a GC because we don't want to have to specify the lifetime of memory ourselves. Rust also has no false sharing between threads, much like Erlang, a thread always owns the memory it operates on.
You don't necessarily have to serialize data between services if one uses something like capnproto or flat buffers.
Why have one heap?