I've never understood this. You can't just combine the state of an old program with new code, without lots of weird things potentially happening. The algorithms and all intermediate products would have to match, at every step of the programs.
(It’s also essentially pointless when your unit of deployment is a disposable container and not a long running lisp system, but it at least makes development a bit nicer)
This is like claiming that you don’t have type errors in Lisp because everything is a list in Lisp. In reality type errors will either manifest in different ways, or still explicitly occur [0].
[0] https://lisp-docs.github.io/cl-language-reference/chap-4/e-e...
This is where the functional programming model really shines - there typically isn't a bunch of hidden state floating around to break hot-reloading
So no, the magic sauce is not “functional”, it’s that CL stemming from the Lisp Machine paradigm is designed for that sort of experience whereas something like Python very much isn’t. And it shows (there’s no image based development in Python that doesn’t end up creating more problems than it solves but image based development is not only the norm in CL but also tremendously empowering).
Are you sure this isn't just doing functional programming, and not realizing it?
It works fine and was designed for this use case.