
Inside Erlang – Joe Armstrong tells his story (2014) - lelf
https://wcm.ericsson.net/en/news/2014/12/inside-erlang--creator-joe-armstrong-tells-his-story
======
jamesblonde
Joe mentions he used to be a physicist and how Erlang contributed to the
discovery of the Higgs Boson.

I heard him tell this joke more than once (we were colleagues): "Higgs boson
walks into a church, and the priest says, 'I'm sorry we don't allow Higgs
bosons to come to churches.'And [the Higgs] says, 'But without me, you can't
have mass.'"

------
nathan_long
I tweeted this about Joe:

> I wish I'd gotten to meet @joeerl. So bright and enthusiastic. Erlang
> embodies so many insights that seem obvious in hindsight. Eg, you can't
> prevent all programmer mistakes. You can't ensure computers never die or get
> disconnected. All you can do is make a system that copes.

> Many programming languages and tools exist to deal with the basic fact that
> humans make mistakes. Type checking, encapsulation, TDD, etc - all because
> without help, we will do dumb things. Erlang taps us on the shoulder and
> says "and ALSO your computer could melt. Start there."

> In Joe's words, "To guard against the failure of an entire computer, we need
> two computers." Obvious. Brilliant.

> The only place you can handle failure of a process on Machine A is in a
> process on Machine B, which can't share any memory with the first process
> and can only pass messages to/from it. And for consistency, Erlang handles
> _all_ failures that way.

> Then you notice that these shared-nothing processes are easy to run
> concurrently because neither can mutate the other's state and cause race
> conditions. And that this scales beautifully when you have multiple CPUs.

> These are some of the insights I got from reading Joe's thesis. I'm sure I
> missed a lot of others and hope to re-read sometime. I wrote up some of what
> I learned at [https://dockyard.com/blog/2018/07/18/all-for-reliability-
> ref...](https://dockyard.com/blog/2018/07/18/all-for-reliability-
> reflections-on-the-erlang-thesis)

~~~
nathan_long
The thesis itself is at
[http://erlang.org/download/armstrong_thesis_2003.pdf](http://erlang.org/download/armstrong_thesis_2003.pdf)

------
barking
I'd never heard of the man before his passing but I don't recall another
person being remembered here with as much affection.

~~~
jaabe
I had heard of him but because no one uses Erlang where I live it was kind of
easy to ignore. I wish I hadn’t though.

Watching some of the talks he’s given on the problems of software in the wake
of his death has been a real eye opener. The physics approach to building a
language which tries to break the laws of physics as little as possible is
truly brilliant.

I don’t know how much time and effort we could have saved ourselves from
wasting if we’d gone with Erlang’s take on concurrency and messaging, but it’s
a lot. Just today I scheduled a meeting where we need to talk about how to
handle messages not making it all the way through a few REST-based sevices.

I doubt we’ll start using Erlang though, it’s just too risky when you can’t
hire anyone, but you do feel a little stupid fighting problems Joe solved
before your youngest hires were born.

~~~
brightball
There's always Elixir where you can get the best of both. There's a lot of
developers out there.

~~~
jaabe
Not in my country.

~~~
brightball
Which country?

------
MarcusE1W
What sometimes puzzels me is that ERLANG is described as quirky and difficult
to read.

I find that once you learned a bit about it for just one day or so it is a
very simple to write language that just flows on the screen from your
thoughts.

So it might look quirky, but really not for long and then it's quite fun to
use. And that's before looking at the ease how you use concurrency, process
restart, hot swap..

~~~
njepa
I think the application of the language is quirkier than the language. There
is a fairly high barrier to doing something ideal. In languages like python or
c you can pretty much just write a few lines and you got something
representative of what you can do. In this thread for example people are
arguing whether you should make command line programs even in elixir:
[https://elixirforum.com/t/elixir-static-app-
binaries/15335/4...](https://elixirforum.com/t/elixir-static-app-
binaries/15335/42)

~~~
dnautics
I started moving my team to elixir mix tasks and it really feels like a
sensible shell script. 1) our scripts must live in our repo, so changes are
tracked with the evolution of our software, 2) many of these scripts are
deployment and resource management, so they share elixir code anyways. 3)
debugging and testing are easier than shell, or even python. 4) one of the
things I'm doing is PXE booting, and we have functional DHCP, tftp, and http
services that are very easily instrumentable can run the lifetime of the
script instead of turning then on and off using some fragile config file
twiddling and sudo systemctl dhcpcd incantation or whatever.

~~~
pieix
Do you mind elaborating a bit on your use case for PXE booting?

~~~
dnautics
sorry, can't give too many details on the specific, but the PXE booting spec
requires that you start up a:

\- DHCP server that responds to broadcasts on 0.0.0.0

\- TFTP server that responds to requests for the bootstrap image

\- HTTP server (for most linux distros, anyways) that fetches more boot
resources that are big enough that TFTP is probably not the best protocol (UDP
doesn't have packet transmission guarantees).

I use a dead-simple, transient erlang HTTP server that my buddy wrote:
[https://github.com/StoneCypher/htstub](https://github.com/StoneCypher/htstub)

And hand-rolled custom DHCP and TFTP servers (existing options are not exactly
what I need) that basically operate like htstub.

This is all tied into a mix task, so you start the mix task, then walk over to
your target machine (or IPMI), reboot it, and then it's provisioned from
scratch, reproducibly, with two-touches. Since everything is done in a single
language, if something is wrong in your provisioning scheme, it's really easy
to figure out what went wrong and deploy a fix.

------
velox_io
Such incredibly sad news that he has passed away, I met Robert Virding a few
years ago (small group of us went out for a meal). I had hardly heard of
Erlang before, followed much more since, plus many of their talks. It's
fascinating how physicists design a programming language/ system, especially
the treading/ distribution model. I think it was WhatsApp the catapulted
Erlang to the limelight (outside of telecoms), it's doubtful that they would
have scaled so quickly had WhatsApp been written in anything else.

Rest in Peace Joe, and my condolences to his friends and family.

