> This is very old-school style, that fell out of favor for... whatever reason this industry likes to make two steps forward, and then 1.9 steps backwards. It s

> This is very old-school style, that fell out of favor for... whatever reason this industry likes to make two steps forward, and then 1.9 steps backwards. It survives in the legacy of Smalltalk and Lisp. To a lesser degree, it's featured in Erlang, and I hear C# these days. The reason is very, very simple: It's hard to do right at any level of complexity. Imagine simple cache server: what about the cache? If binary format changed, you either have to have some migration code or you need to throw it away. Once you threw the cache away you might as well just restart the server in the first place, if you want availability you need 2+ servers anyway so it buys you few seconds of boot time at most. If all you need to replace is a bunch of function calls sure, that's doable but what if new function takes some extra arguments (or just struct that it gets passed changes) ? If you have well-defined lines (like plugin APIs to use, or ability to load the "logic" part as separate thing) it can work but otherwise it is a LOT of work and bug potential to gain not that much. Better to focus on making seamless update (in case of apps used directly by users), or in "server" apps realize you need redundancy, code reload or not, so just focus on good deployment process.