<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 17 Oct 2011, at 23:14, Gerry Weaver wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">It has been my experience that network servers most often fail due to OS or hardware limits rather than<br>bugs in the code (at least for thoroughly tested production ready code). When you factor in the amount of baggage that comes with Erlang, or any other VM based language, it's difficult to justify.</span></blockquote><br></div><div>Gerry,</div><div><br></div><div>You have been given other helpful answers from the good people of this list. I thought I'd add something from my own experience writing commercial code in Erlang.</div><div><br></div><div>The thing I've noticed about Erlang-based systems is that they tend to mature very well.</div><div><br></div><div>I attribute this to a number of things:</div><div><br></div><div>== Functional programming style ==</div><div><br></div><div>The parts of your code that rely on pure functions (no side-effects) have the nice property that once you have weeded out the bugs, the code *stays correct*, until requirements change. I've seen this in industrial erlang-based systems: they have been robust from the start, but the quality just keeps going up.</div><div><br></div><div>== Error handling + programming for the correct case ==</div><div><br></div><div>The combo of pattern-matching, purely functional style, and process supervision, further support the notion of writing functions that are correct by design. They do what they are supposed to for expected input, and simply crash for unexpected/invalid input. This style of programming actually works very well as a *default* in Erlang. For extra robustness, one usually needs to trap and handle errors especially in a few places, but that kind of hardening is fairly straightforward, and can be done as incremental improvements.</div><div><br></div><div>== Ability to limit the state-event space ==</div><div><br></div><div>It's been mentioned that Erlang shines especially for control and coordination scenarios. An important reason is that Erlang allows you to minimise the interference between different components and events. In many design approaches, it is very hard to introduce new protocols or events, as the effects cut across the code in a very bad way. For many systems, this has the effect that they don't mature well. Changes in traffic conditions, hardware and network topologies, and requirements all have a tendency to trigger a new flurry of bugs, due to things happening in a different order than before, or events combining in unexpected ways. I have compared this to the evils of GOTO programming [1].</div><div><br></div><div>Given the old rule of thumb that 80% of the lifecycle cost of a system lies in evolution and maintenance, this makes of a pretty formidable advantage.</div><div><br></div><div>In one system I worked with, our first release was 4x better than the company norm on faults/KLOC. After a few releases - with significant feature growth - we were 12x better. Code that was corrected for bugs tended to stay correct, and bug fixes normally didn't introduce any new bugs.</div><div><br></div><div>A colleague of mine, Mats Cronqvist, once wrote in a workshop paper [2], after having analysed some 150 trouble reports from function- and system testing:</div><div><br></div><div>"Most of the errors were not coding errors, but simply a working implementation of the wrong thing." (page 2)</div><div><br></div><div>Another way of putting it would be that there are comparatively few "accidental errors" in Erlang-based systems - that is, errors that are a consequence of the implementation technique rather than a misunderstanding of the requirements.</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><div>[1] <a href="http://www.infoq.com/presentations/Death-by-Accidental-Complexity">http://www.infoq.com/presentations/Death-by-Accidental-Complexity</a></div><div>[2] "Troubleshooting a Large Erlang System", Mats Cronqvist, 2004 ACM/SIGPLAN Erlang Workshop</div><div> <a href="http://dl.acm.org/citation.cfm?id=1022474">http://dl.acm.org/citation.cfm?id=1022474</a></div><div> <a href="http://www.erlang.se/workshop/2004/cronqvist.pdf">http://www.erlang.se/workshop/2004/cronqvist.pdf</a></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>