<div dir="ltr">We used it hot code reloading a lot at Mochi and found it quite useful for many of our incremental updates. The trouble is when you change too much about the messages or data types flowing through the system you will have to write a fair amount of code to gracefully handle the code change, so you might not want to use it for every upgrade. It's of course also not possible to upgrade the VM with hot code reloading.<div>
<br></div><div>Folks who like to deploy updates with one type of sledgehammer simply can't choose hot code loading as it's not a general solution to the problem, so if you're going to teach or recommend just one way you wouldn't cover it. Your system should be able to handle a hard crash of a node anyway so a rolling restart to upgrade should work fine (but might not be very fast or efficient).</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 11:02 AM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've never had a situation where I've needed hot code loading, but a project<br>
that may be a good fit with this feature is looming (and may not be a good fit<br>
-- I have much to learn about this feature). Nearly all the advice I see on<br>
this is to avoid it in production, which seems highly ironic, since this<br>
feature was designed specifically to ease certain cases of production.<br>
<br>
The advice against using it mostly comes from tutorials, presentations and<br>
asides made by various speakers in talks I've seen. I don't have a canonical<br>
"don't use hot code loading" reference, but I have exactly zero references<br>
which urge the use of this feature and explain in depth how to integrate it<br>
with a release cycle.<br>
<br>
But someone worked a long time figuring out how to make this a part of the<br>
runtime, so...<br>
<br>
Is this feature:<br>
A) "Hard" to use because it is far outside the experience of the average Java-<br>
or web-developer-turned-Erlanger who tends to give talks about Erlang.<br>
B) "Hard" to use because it is actually hard: a technically complex feature<br>
for which little scaffolding is available for easy integration.<br>
C) Actually not very useful.<br>
D) People have been trained to accept maintenance downtime and believe that<br>
loadbalancers are the answer to everything?<br>
<br>
Most of the best tools I've ever used fell into category (A), so I wonder if<br>
that is the case with this feature. Some things I've really liked in<br>
environments like Guile fell into category (B), which was nice because after<br>
some thorough study something complex but understandable can be abstracted and<br>
made easy to use. I have a hard time believing that this feature actually<br>
falls into category (C), feeling it is much more likely that widespread<br>
acceptable of the (D) view simply obviates much deep thought on the utility of<br>
it in the first place -- especially since so much focus, even within the<br>
Erlang community these days, is on the web and not other areas.<br>
<br>
Can anyone provide some insight into this? I'd rather get some opinions now<br>
than spend time getting to the bottom of a relatively untaught feature only to<br>
find that it wasn't very useful.<br>
<br>
-Craig<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>