<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 9:39 AM, Torben Hoffmann <span dir="ltr"><<a href="mailto:thoffmann@basho.com" target="_blank">thoffmann@basho.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":rd" class="a3s" style="overflow:hidden">For me one of the key business values of Erlang is that if you have done<br>
your supervision tree well, then you can add new services to your system<br>
without worrying. If you have created something that fails, the only<br>
that part fails. The rest of your system continues.</div></blockquote></div><br></div><div class="gmail_extra">IMPORTANT: Before doing anything regarding management, you should watch lots of Mike Williams talks. Some things which "sound good" to the technical programmer are bitter pills for management. You should also hope Joe Armstrong chimes in on this thread :)<br><br></div><div class="gmail_extra">Erlang systems give you something almost for free due to their construction:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* Systems are isolated by design in Erlang, so failure in one subsystem is less likely to affect other subsystems. In contrast to most other solutions, the granularity of an isolated unit is much smaller, so faults usually have much less impact on the perception of the system as a whole.<br><br></div><div class="gmail_extra">* Failure and risk are easier to control: if a subsystem fails, Erlang reestablishes that subsystem from a known good state. This means you can make a call of when you want to fix it, rather than having to fix it ASAP in many cases. In turn, you get operational freedom to decide when to fix problems and can postpone less severe problems till later, or outright ignore them.<br><br></div><div class="gmail_extra">* Erlang systems automatically snapshots system state under failure for post-mortem analysis and debugging. This helps when failures occur as the system can continue running, but you have a good data set for figuring out what went wrong so it doesn't happen again. Not only do you have a backtrace, you also have the state which lead to the failure.<br><br></div><div class="gmail_extra">Compared to C/C++ specifically:<br><br></div><div class="gmail_extra">* Higher level language, so you can iterate faster and try out more ideas in Erlang. It makes it more likely you get the architecture right. Once you lock onto a solution in C/C++ that decision tend to be set in stone for a long time.<br><br></div><div class="gmail_extra">* If your problem has natural distribution/concurrency, Erlang is likely to perform as well as C/C++ solutions due to the amount of time sunk into the Erlang VM.<br><br></div><div class="gmail_extra">* Erlang programs tend to be easier to reason about from a correctness perspective[0]<br><br></div><div class="gmail_extra">[0] Don't fall into the trap of mentioning Functional programming. Yes, that is the underlying reason, but give the consequences.<br><br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>