[erlang-questions] Why (not) hot code loading

[Michael Loftis]

A, B, D ....  The actual concept is easy and works well...it gets hard
because you're replacing a module which may or may not have in-flight
messages, and which may (or may not) change it's interface to other
modules.  Thats where the hard bits come in, you really have to
understand, appreciate, and have well defined APIs and behaviors
thought out for upgrading or you may find yourself with odd bugs or
just crashing the whole supervision tree.  Hot code load is really
great for internal bugfixes but gets much harder when you're making
major changes.  And thats also where there's a lack of tooling -
getting dependencies properly reloaded/loaded if they change, that
sort of thing.



On Fri, Jun 20, 2014 at 11:02 AM, zxq9 <zxq9@REDACTED> wrote:
> I've never had a situation where I've needed hot code loading, but a project
> that may be a good fit with this feature is looming (and may not be a good fit
> -- I have much to learn about this feature). Nearly all the advice I see on
> this is to avoid it in production, which seems highly ironic, since this
> feature was designed specifically to ease certain cases of production.
>
> The advice against using it mostly comes from tutorials, presentations and
> asides made by various speakers in talks I've seen. I don't have a canonical
> "don't use hot code loading" reference, but I have exactly zero references
> which urge the use of this feature and explain in depth how to integrate it
> with a release cycle.
>
> But someone worked a long time figuring out how to make this a part of the
> runtime, so...
>
> Is this feature:
> A) "Hard" to use because it is far outside the experience of the average Java-
> or web-developer-turned-Erlanger who tends to give talks about Erlang.
> B) "Hard" to use because it is actually hard: a technically complex feature
> for which little scaffolding is available for easy integration.
> C) Actually not very useful.
> D) People have been trained to accept maintenance downtime and believe that
> loadbalancers are the answer to everything?
>
> Most of the best tools I've ever used fell into category (A), so I wonder if
> that is the case with this feature. Some things I've really liked in
> environments like Guile fell into category (B), which was nice because after
> some thorough study something complex but understandable can be abstracted and
> made easy to use. I have a hard time believing that this feature actually
> falls into category (C), feeling it is much more likely that widespread
> acceptable of the (D) view simply obviates much deep thought on the utility of
> it in the first place -- especially since so much focus, even within the
> Erlang community these days, is on the web and not other areas.
>
> Can anyone provide some insight into this? I'd rather get some opinions now
> than spend time getting to the bottom of a relatively untaught feature only to
> find that it wasn't very useful.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler