In Erlang, you can definitely send a fun and arguments to be run on a different node. And a lot of processes are built around passing in State as an argument and rerurning the NewState in the return... So you might not need a lot of work to adapt to moving processes around. Not really moving processes though; starting a new process with the old state and killing the old one.

You would need to be careful with the process dictionary (either don't use it, or copy it over), and you'd need a way to disseminate the new process identity and to forward messages arriving at the old process. Dealing with links and monitors would be doable. The process couldn't have Port references, so no sockets or open files or driver references; those aren't network transparent and I assume you'd be doing process migration as part of node migration so those ports would have to be closed soon anyway.

I'm having trouble coming up with a usecase that this would enable. But... at WhatsApp we did do something conceptually similar I guess when a client connected on a new connection before the old connection was detected closed. The new client2server process would message the old process and the state would be transferred ... but you would probably do that in any language.

Anyway, sounds fun!

It used to be popular to do this in Scala (with Akka). You serialise a LocalTaskRef and send it across the network, resume it on another host

Java's RMI sounds similar ... but I haven't really seen much of that used in a robust way. You can only ship serializable state which becomes quite limiting after a while. Shipping the data and reusing the same code across nodes seems to accomplish the same thing with less headaches.