Network connections aren't the hardest problem; you can hand those across Unix sockets.

The fundamental problem with hot reload is that data structures can change. If the old process has a priority queue implemented as a linked list and the new process has a priority queue implemented as a heap, how on earth is any automated mechanism going to copy the state across?

Changing the running code but keeping the data in memory is equivalent to changing the code but keeping the data in the database. Changing data-structure definitions is equivalent to changing the database schema.

If you want to change the database schema without losing data, you need to write a migration. If you want to hot-reload code with different data-structure definitions, you'll have to write a migration.

A hot-reloading solution for a statically typed programming language will at minimum have to detect whether data structures have changed and either prevent the reload or require that the new code includes a function to migrate the data.

I guess you could come up with some concept of migrations for data structures?

Obviously, you write a code_change/3 function that updates the old state to the new shape or, if asked to do so, downgrades the new state back to the old shape :)

In languages like Common Lisp it is quite well solved, even in space.

http://www.flownet.com/gat/jpl-lisp.html

> The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.)