[erlang-questions] Erlang and Akka

[Jesper Louis Andersen]

On Thu, Aug 28, 2014 at 2:18 PM, Fred Hebert <mononcqc@REDACTED> wrote:

> There is value in having an entire community align their development
> style to what you tend to need, whether forced or not.
>

More importantly: when you write an Erlang application/library you buy into
the core values of Erlang:

* Isolation
* Message passing by copying
* Strict resource constraints and who owns resources
* Error channels in the form of monitors and links
* Fully preemptive multitasking among processes
* Seperate heap per process with GC per-process
* Purely functional core language
* Asynchronous messaging with possible loss
* Self-describing data layout in memory

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.

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.

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.

-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140828/61dddee3/attachment.htm>