<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 1:53 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- Software quality: Immutability basically goes together with referential transparency, and you should aim to write as many functions as possible in a side-effect free way. Once such a function has been debugged and works correctly, it *stays* correct, until the requirements change. For this reason, legacy Erlang code can truly become rock-solid.</blockquote>

</div><br>I've had the same experience in three projects now of larger size:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Once your Erlang system is up and running and you weeded out the most glaring bugs, the system becomes rock solid. In all three projects, the requirements are set in stone and won't change right away[0]. All three systems has been running for months now, with no intervention. And they all process around 20-30 requests per second. One particular system has been doing this for over a year without any intervention, no reboot. Subsystems around the Erlang systems have died left and right, but the Erlang-systems themselves do not care about such misbehaviours. They automatically recover once the subsystems become healthy again.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I have a hunch that this property is also making Erlang programmers more productive: Once your system is written, there is very little to maintain. So your programmers go off and does more productive stuff. In a world where the system keeps failing, you reset the programmer back to that system again and again. This hampers productivity in the long run.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">[0] This is one of the ways you know you got the design right. You can isolate the parts of the system which has to change from the parts of the system which don't. When this works, things fall out really well usually. Everything hinges on getting the specification right so you can figure out what parts of the system needs to change going forward. And then freeze/lock down the parts that don't, preferably with property based testing.<br clear="all">

<div><br></div>-- <br>J.
</div></div>