Erlang Hot Code Loading

Question

As per Erlang Documentation, Code Loading, Erlang only maintains 2 versions of a module, current and old.
Why it does not keep multiple versions of old code on code reload and do not kill the processes lingering in the old code.

Answer 1

It's a conservative approach which guarantees that after 2 upgrades of a module, you can be certain that you don't have any process still executing older versions of that code. This means that you know that old bugs or vulnerabilities are flushed out, and that no code still expects old data formats (in memory or on disk) or sends/receives old forms of messages between processes.

Originally, the 2-version implementation was probably motivated by the need to be able to keep a node running for a very long time without restarts, and on hardware with relatively little RAM compared to systems of today, so code upgrades should not risk leaking memory in the form of old module versions that cannot be deleted because the call stack of some process is still referencing it. While this can still be of concern, I'd say that the reasons I listed above are the primary ones these days.

So while it is an implementation detail, and you could have an Erlang implementation that allowed any number of versions in flight, with automatic garbage collection of unused code, nobody who is running production systems has ever seemed to want this. It would just add a larger window of uncertainty to the state of a running system. The 2-version implementation offers a clean way of evolving a system without stopping it.