That's kind of how Erlang is. At first, anything Erlang has, some other system has too:
Isolated process heaps? - Just use OS processes
Supervision trees? - Use kubernetes.
Message passing? - Not a big deal, I can write two threads and a shared queue in Java.
Hot code loading? - Java can do that too
Low latency processing? - I can tune my LMAX disruptor to kick Erlang's butt any day.
Now getting all that into one platform or library that's the main idea. OS processes are heavyweight. Running 2M of them on a server is not easy. You could use some green threads or promises but now you lost the isolated heap bit.
You can use kubernetes to some degree but it does not do nested supervision trees well. I guess it would work, but now you have your code, and you have pods and controllers, and volumes and all the shit.
You can do message passing with an "actors" libraries in many language. But you cannot do pattern matching on receive, and it doesn't transparently integrate with sending it across nodes to another thread.
You can do hot code loading, but how do you deal with runtime data structure and state. Erlang is built around that: gen_servers since the state is immutable and explicit has callbacks to upgrade not just the code but the state itself.