&gt; This would be terrible in production...<p>Yeah it could be. Frankly, I&#x27;d likely reach for Erlang Releases before I reached for this when updating software in production.<p>However, for a <i>large</i> variety of dev work, this automatic module reloading thingie works pretty well. :)<p>&gt; You could pretty easily use code:soft_purge&#x2F;1 prior to loading to avoid killing lingering processes though...<p>Mmm. Okay. So, I&#x27;m not 100% on how this works, so please bear with me and my inaccurate terminology. :(<p>In any given Erlang system, there can be two versions of a module running, the &quot;current&quot; one, and the &quot;old&quot; one, right?<p>So, if you call code:soft_purge&#x2F;1 when there is no &quot;old&quot; code loaded, it should return true, yes? (In addition to returning true when there&#x27;s no process running the &quot;old&quot; code.) [0]<p>So, would this be a way to write an auto-loader that doesn&#x27;t purge in-use code?<p>* code:soft_purge(?MODULE)<p>* if false, wait a while then retry<p>* if true, code:load_file(?MODULE)<p>I guess maybe you&#x27;d want to build up a list of all the modules that have been modified, and wait until code:soft_purge&#x2F;1 returns true for all of them before loading the modules. (maybe.)<p>You also -obviously- want an override that allows for the purging of in-use code.<p>[0] Testing <i>indicates</i> that it does, but it&#x27;s often good to double-check. :)