
The Zen of Erlang (2016) - swyx
https://ferd.ca/the-zen-of-erlang.html
======
rapsey
I’ve seen ex python or node.js developers say they are just as productive in
Rust.

After a few years of Rust experience, it still pales in comparison to Erlang
productivity for me.

~~~
k_bx
I'm really looking forward for Hamler lang to become mature and popular
[https://github.com/hamler-lang/hamler](https://github.com/hamler-lang/hamler)

It's based on PureScript, which has a great reputation, but adds all the
benefits of Erlang.

~~~
brightball
Running on the Erlang VM and all the benefits of Erlang aren’t the same thing.
Erlang itself is based on a very carefully constructed set of trade offs. You
don’t add something without giving up something else.

~~~
dnautics
As long as you give an escape hatch to access the Erlang VM, the rest is
somewhat superficial. I am way more productive in Elixir than I am in Erlang,
but that's probably because of the way my brain is wired.

> very carefully constructed set of trade offs

But also the VM has changed since 1980 (for example there are maps now) and
the programming ecosystem has changed (we know what drives productivity in
terms of how to effectively test, document, deploy, good documentation >
separate header files), we also know more about things like how lexical
metaprogramming is maybe not the best idea for IDEs or language servers, it's
really tough to say that Erlang got everything right for time immemorial. And
on some things Erlang hasn't moved yet (thankfully it seems like there's
movement in documentation).

~~~
brightball
True, I’m mainly talking about stronger types. It’s something people have
asked for a lot and generally the trade offs aren’t taken into account.

Elixir aimed for 100% Erlang compatibility.

------
vyuh
_This is a loose transcript of presentation given at ConnectDev '16._

Video of the presentation:
[https://youtu.be/4ZIPijEqrNI](https://youtu.be/4ZIPijEqrNI)

------
j_m_b
Is Erlang about to be the next big thing due to companies unable to use Huawei
and instead going with Ericsson for 5G deployment?

~~~
s3cur3
The Erlang ecosystem (including my personal favorite BEAM language, Elixir)
has been kind of a secret weapon for a lot of companies for years. There are a
handful of freelancers in the community who have had the experience of going
to work for a company doing Erlang/Elixir, only to be told they can never
reveal the company’s identity because they consider the language a competitive
advantage. One big corp went so far as to say they use Java in all their
public-facing info (including hiring).

~~~
apta
What does Erlang offer that the JVM or .NET don't?

~~~
smabie
While there is actor support through Akka and Akka.net on the JVM and .NET,
neither of them support preemption like the BEAM does. Preemption of blocking
actors is a _game-changer_ in terms of how you write and structure concurrent
code. I wrote a BitTorrent client in Scala using Akka and found myself
desperately wishing that I could write actors in a blocking style. The amount
of extra complexity and book-keeping required to write purely non-blocking
actors is truly staggering.

Let me give you an example. I have an actor that asks for two objects from a
DbActor, and then sends them to the AdderActor to get the sum. Without
preemption, I have to do the following.

1\. Send a message to get object A and object B. Return.

2\. Wait for an object.

3\. When I get the object, figure out if it is object A or B (or maybe it's
something else entirely). Update internal state so that I know I need one more
object. Return.

4\. Wait for an object

5\. Get the object, figure out if it is object A or B (or something else).
Update internal state so I know that I have both objects. Send the two objects
and my Add message to the AdderActor. Return.

6\. Wait for the result.

7\. Now that I've gotten the result, update internal state saying that I've
completed my A+B operation. Either store the result of A+B or whatever.

This method requires a lot of internal booking and a lot of mutable hash
tables in order to keep track of all the various stuff this actor is in the
process of doing. If I'm trying to calculate A+B and C+D, I need to know how
far along I am in each computation. This is a buggy and annoying process that
creates a ton of complexity.

Let's look at how we could do it in Erlang:

1\. Send a message saying we want object A.

2\. Don't return, and instead block until we get A. Now we ask for B.

3\. Block until we get B. Now send the A+B message.

4\. Block until we get it. Do something. Return.

See how much easier this is? Because we can block, our code actually can be
structured to look like normal, non-concurrent code. It can be executed in a
sequential fashion, even though the actual computation is happening somewhere
else. With Akka and Akka.net, we can't do that. We have to return as quickly
as possible, or else we are going to lock up the entire system. This means
that all of the implicit state that a normal program has (like current line
being executed), must be stored _explicitly_ by our program.

It sucks, but hopefully the JVM will get preemption sometime soon. The actor
model doesn't really work with out it. And even though it doesn't work without
it, it's still better than threads and mutexes.

~~~
sbalea
In Scala/Akka, you could use the ask operator and compose the resulting
Futures, something like this:

    
    
      for {
        a <- aProviderActor ? gimmeA
        b <- bProviderActor ? gimmeB
        aPlusB <- adderActor ? (add, a, b)
      } yield aPlusB

~~~
smabie
Yeah, but you're blocking the thread. It's very very easy for you to deadlock
the entire system writing code like this.

------
dang
If curious see also

2018
[https://news.ycombinator.com/item?id=17100626](https://news.ycombinator.com/item?id=17100626)

Discussed at the time:
[https://news.ycombinator.com/item?id=11058500](https://news.ycombinator.com/item?id=11058500)

------
amelius
I have the feeling that Erlang is great, but only if you are working in a very
specific problem domain.

For example, I wondered if there is a GUI library for Erlang, and the response
with the most votes here [1] is that people don't write GUIs in Erlang.

The other answers point to wrappers around libraries written in other
languages.

I think that is suspicious for a language that has been around for such a long
time now.

[1] [https://stackoverflow.com/questions/97508/what-libraries-
can...](https://stackoverflow.com/questions/97508/what-libraries-can-i-use-to-
build-a-gui-with-erlang)

~~~
dnautics
check this out:

[https://www.youtube.com/watch?v=feAW1AVzNwo](https://www.youtube.com/watch?v=feAW1AVzNwo)

But also there are GUIs (I believe there are wx bindings) that are _shipped_
with erlang (wobserver for example)

By and large, though people are writing servers in erlang, so building GUIs
has never been a priority, and by the time erlang got a kick in butt in
popularity due to Elixir, the way to write a GUI in erlang, became "write a
web interface in Elixir".

Finally don't necessarily trust stackoverflow; the entire elixir community has
basically left SO and gone to elixir-specific fora, which we think is why
elixir dropped off the SO developer's survey.

~~~
zbentley
> the entire elixir community has basically left SO and gone to elixir-
> specific fora

That's very surprising to me. Do SO's metrics of questions/answers/etc reflect
this? If so, why the move? Was it organic? Organized?

~~~
mononcqc
I was active on the Erlang stackoverflow.

I left because stackoverflow is not a community, I don't give a crap about the
gamification, the incorrect answers most upvoted because they provide a
quickfix rather than a proper fix, and I'd rather go in places where you can
have an actual discussion when you need to re-frame problems since newcomers
aren't generally used to the paradigms of the VM and OTP.

Stackoverflow felt like working for free just spending time answering things
for imaginary points whereas other fora have more reciprocity available
through richer dynamics that can help build communities.

Stackoverflow, to me, is a last resort more than anything else.

------
e_carra
I watched the presentation some months ago on YouTube. Really really well
done. Thanks to that video I was able to get some tricky concepts of Erlang
that I was previously struggling with.

------
bobbyz
The incessant functional evangelizing everywhere I go reminds me of why people
don't like vegans

------
MrFantastic
Immutable variables are too weird for me.

~~~
dnautics
If you are willing to get over it, you'll find that huge classes of errors
disappear. It's a very nice feature that lets you cut a bunch of bs, clarify
your code, and make everything much more comprehensible. When you can mutate
your values, you have to read any given block of code with a ton of suspicion
(and possibly trace through control flow, keeping branches in your head, god I
don't miss doing that). If your values are immutable, you don't have to do
that.

The one place where it screws you over in erlang is the REPL, which I think is
why Elixir chose to allow you to mutate the variable binding, (but the
underlying values are still immutable). In my main code, I mark any variables
that I will mutate binding (almost never) with a ! postfix sigil (idea stolen
from Julia/Ruby)

