
The Erlang Rationale - lelf
https://rvirding.blogspot.com/2019/01/the-erlang-rationale.html
======
jstewartmobile
I think the world of Joe Armstrong (may he rest in peace), and was really
excited about jumping into this world. In practice, I think this philosophy is
better on paper than in the real world.

Start with message passing over multiple processes. The Erlang/Elixir
ecosystem leans toward lightweight processes and message passing for
everything. Isolation is great, but it has a cost. Part of that is paid in
reduced inspectability. Good luck getting a meaningful stack trace, or
figuring out what someone else's code does, when even the simplest action is
split over a half-dozen concurrent processes and supervisor trees. I know it's
a bridge that eventually has to be crossed, but a very expensive one!--like
pouring the foundation for global HQ before the first customer has even
signed.

Dynamic typing is another pain point. Wrangling types is not fun, but to keep
growing something, they're non-negotiable. Facebook and Hack. Microsoft and
TypeScript. The preponderance of C# and Java in the enterprise world, and C++
in games. These weren't accidents of history. Without mandatory compile-time
type-checking, re-factoring eventually becomes so perilous that it is avoided,
and the product withers. Why they chose that in a "robustness" language is a
head-scratcher.

Also, the compiler is slow--which wouldn't be so bad if it caught more errors
(like type mismatches), but it doesn't.

~~~
elcritch
In my experience the stack traces from Elixir (or even Erlang) are pretty
useful. Sure there isn't a full stack trace back to a main function however
that really isn't different than a framework with any level of indirection.
Given the choice between a C#/Java stacks trace 40 lines deep and a BEAM
stacktrace of only 6 lines I'll take the latter. Even better you get both the
value of the last received message and the state of the process in the stack
trace makes reproducing an issue simple.

Based on what you're saying given the lack of inspectability it sounds like
you haven't tried out some of the introspection capabilities of BEAM. Maybe
you have, but I've seen little that compares to the Observer module that comes
included in a language. Realtime introspection of processes and the ability to
see the message queue for any process makes inspecting the whole system very
interactive and powerful.

There's a point that message passing lowers max performance, but given the
rise of multicore processors it's pretty powerful platform. Future hardware
likely could weaken memory coherency between cores which could be taken
advantage of by BEAM. Overall it takes a different mindset to work well with
Erlang philosophy IMHO.

~~~
hinkley
I'm getting the same issue with async/await in Javascript and I'm worried
about the same happening in Rust.

There should be a way to extend these traces. I don't know what the costs
would be like to trace back across calls, but I would expect they should be
somewhat reasonable in the case where the caller expects a response (you
already have the bookkeeping and the stack frames).

~~~
joshuahutt
>As of V8 v7.3, --async-stack-traces is enabled by default.
[https://v8.dev/blog/fast-async](https://v8.dev/blog/fast-async)

~~~
hinkley
Yeah we aren't on 12 yet. In fact we just got off of 8.

------
MaysonL
Should be of interest to anybody interested in this, Joe Armstrongs Ph.D.
thesis:
[http://erlang.org/download/armstrong_thesis_2003.pdf](http://erlang.org/download/armstrong_thesis_2003.pdf)

~~~
vardhanw
Is this better of an introduction to Erlang (and in general distributed fault
tolerant systems) than other sources (e.g. programming Erlang)? I come from a
telecom background and worked on high reliability/robust systems, somewhat on
the principles of this book [1]. Wanting to learn Erlang.

[1] Robust Communications Software: Extreme Availability, Reliability and
Scalability for Carrier-Grade Systems - Greg Utas

~~~
rramadass
Am a noob in Erlang studies but i have settled on the following three books.

1) Introducing Erlang: Getting Started in Functional Programming. - Just to
get an easy intro.

2) Programming Erlang: Software for a Concurrent World by Joe Armstrong
himself.

3) Erlang and OTP in Action - This one seems to be the advanced book.

------
ggm
A not very useful level of indirection: it's a blog pointing AT the Erland
rationale, not the rationale itself.

------
fortran77
It's a shame that the elegance of Erlang has been distorted with Elixir.

~~~
toast0
I don't particularly care for Elixir, but it's kind of nice having more people
on the BEAM.

~~~
BoorishBears
I don't think the above comment is put in the best way...

But I do have a certain duality about my feelings on Elixir

On one hand, yes, it is cool to see more adoption of BEAM, I do wish Erlang
could have done that by itself.

I vastly prefer Erlang to Elixir and find it does slightly... taint the
simplicity and cleanliness of the syntax Erlang made made me fall in love
with, just to be Ruby-like.

I don't feel it actually benefits the language at all past the meta reason of
attracting Ruby-ists (which again, isn't necessarily a bad thing by itself)

~~~
jeremy_k
It's interesting that you would say a language could 'taint the simplicity and
cleanliness of the syntax' of another language. You can still work purely in
Erlang and not deal with Elixir can you not?

I'll say my own personal experience is that I knew of Erlang but had never
really looked into it or knew of the benefits of OTP and BEAM. Being a
Rubyist, Elixir bridged that gap for me and I've been reading more and trying
to learn more about this new (to me) environment.

I would also say that Elixir has benefited Erlang because José hasn't just
built Elixir, but has gone and helped implement new things into Erlang; the
entire environment is benefiting from drawing in new engineers.

~~~
b3orn
My problem with Elixir is kind of similar to C/C++. Interfacing with C code
from C++ is easy, interfacing with C++ code from C isn't easy and you end up
with loads of ugly wrapper code. The same goes for Erlang and Elixir,
interfacing with Erlang code from Elixir is easy, interfacing with Elixir code
from Erlang is ugly. And the more people start writing code in Elixir I fear
that more people are turning away from Erlang. And even if the entire
environment in total benefits from more people using Elixir, that environment
will more and more turn into an almost pure Elixir environment with very
little of Erlang left.

