These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been developed with a focus on functional techniques and careful management of application state.
This probably doesn't sound like a significant difference, but in practice, it is a huge boost to productivity, especially in a non-trivial app where reloading the entire app and then reproducing the app state manually with every file change can become quite tedious.
* CHANGE-CLASS (change the class of an object to a different class),
* update-instance-for-different-class (updating the object after a class change, one can provide methods which will be lazily called when needed),
* update-instance-for-redefined-class (updating the object after redefining a class, one can provide methods which will be lazily called when needed),
* LOAD (load source or machine code),
* EVAL (eval expressions)
* COMPILE (compile code in memory to memory), ...
Hey cool, I can change these classes live!
Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem.
2 years later...
What's causing this super-weird bug? It's like the code isn't doing what it says at all.
1 week of debugging and head-banging later...
Oooh, something got screwed up in that runtime class change code. Fixed.
2 years later, repeat...
In the types of apps I think we're talking about, typically most state is in the database and not much is going on in the client.
I believe I used something similar called fam in the 90's but that may have only been on SGI.