It's definitely a possibility to design some form of RPC mechanism and have multiple parts of your application run as essentially a distributed system. There would still be the problem that the "main" application part is expecting the rest of the system to behave in a certain way and if it is maintaining state, the state to be in a certain form. So I'm not sure that you would really win much.

Also, part of the idea is to make hot-reload as little additional burden as possible. Proper compiler support would be the real solution to that but in the form presented in the article you can at least quickly switch between an efficient static build and a dev version, something that would be hard to achieve with an RPC mechanism.

> Are self updating processes really the right abstraction?

As a debug tool, absolutely. As as a normal part of program execution in production? A bit sketchy. But that said....

... what if there was a sure way to directly map your entire program state into the new version and you could be assured that you didn't miss any obscure corner of the state space? Like a borrow checker for transitioning between program versions. That'd be pretty neat.

Agreed, I made something similar to live patch services w/o downtime and despite being cool I'm not sure I'd recommend it vs. just putting replicated containers behind a load balancer.

Sounds like Erlang from what I’ve heard about it