[erlang-questions] Erlang for managers

[Jesper Louis Andersen]

On Fri, Feb 26, 2016 at 9:39 AM, Torben Hoffmann <thoffmann@REDACTED>
wrote:

> For me one of the key business values of Erlang is that if you have done
> your supervision tree well, then you can add new services to your system
> without worrying. If you have created something that fails, the only
> that part fails. The rest of your system continues.
>

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 :)

Erlang systems give you something almost for free due to their construction:

* 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.

* 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.

* 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.

Compared to C/C++ specifically:

* 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.

* 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.

* Erlang programs tend to be easier to reason about from a correctness
perspective[0]

[0] Don't fall into the trap of mentioning Functional programming. Yes,
that is the underlying reason, but give the consequences.





-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160226/03d50f11/attachment.htm>