<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 2:18 PM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":12i" class="a3s" style="overflow:hidden">There is value in having an entire community align their development<br>


style to what you tend to need, whether forced or not.</div></blockquote></div><br>More importantly: when you write an Erlang application/library you buy into the core values of Erlang:</div><div class="gmail_extra"><br>

</div><div class="gmail_extra">* Isolation</div><div class="gmail_extra">* Message passing by copying</div><div class="gmail_extra">* Strict resource constraints and who owns resources</div><div class="gmail_extra">* Error channels in the form of monitors and links</div>

<div class="gmail_extra">* Fully preemptive multitasking among processes</div><div class="gmail_extra">* Seperate heap per process with GC per-process</div><div class="gmail_extra">* Purely functional core language</div>
<div class="gmail_extra">
* Asynchronous messaging with possible loss</div><div class="gmail_extra">* Self-describing data layout in memory</div><div class="gmail_extra"><br></div><div class="gmail_extra">Erlang programmers cannot avoid any of these core values in any way when they write code. This is not true in Java/Akka, Go, Haskell, OCaml, C++, Python, Ruby, Node.js or what-have-you. In Erlang, any decent library is able to interoperate with other systems quite easily since it has to be isolated by construction. In almost every other language you have to worry about reentrant code, mutex locks around critical sections, that each application library has its own way of doing thread pools and so on.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Of course, you can *pick* a style and follow it, blindly. But then you have to adapt any library you are going to use to this style. Node.js fares way better than the comptetion here because it did pick a writing style initially. It picked the wrong one, for several reasons, but consistency wins. Go actually doesn't fare much better here than C++ since it also requires the programmer to be wary of when a given subsystem is safe to use or not. Simply because there is shared memory and shared memory forces you to potentially abort all of the program on any memory-inconsistency error, however small.<br>

<br clear="all"><div>As an aside, this is also why it is usually not that beneficial to speak about how performant Erlang programs are compared to their counterparts. There is a price for these core values in execution, and you have to pay that price in Erlang. Once you make that sacrifice however, you get the value of robustness and stability. And, perhaps more importantly, maintainability; the by far most costly endeavour in any software project.</div>

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