
Why the Cool Kids Don't Use Erlang [video] - pmoriarty
https://www.youtube.com/watch?v=3MvKLOecT1I
======
jallmann
I tried to do a startup in Erlang a few years ago. Haven't been able to watch
the video because there aren't subtitles or a transcript, but here is why I
don't use Erlang anymore: the type system. Erlang/OTP does MANY things
correctly, where "correctly" is taken to be "in line with my tastes", and yes
this includes the inane issue of syntax.

But the type system? Normally that wouldn't bother me, but I'm coming from
OCaml, where exhaustive checking of algebraic data types makes me invincible.
With dynamic typing, my code feels extremely vulnerable, especially when
refactoring a codebase. Of course, Erlang isn't alone in this (I abandoned
Ruby for similar reasons), but the pain of refactoring feels more acute in
Erlang -- perhaps because idiomatic Erlang uses many short functions, making
it easy to miss usages. So you have to rely on run-time testing to ensure
complete coverage -- and that is nowhere near as easy nor reliable as a
compiler that automatically checks everything for you.

My dream language is one with ML semantics running on top of BEAM. That seems
like a natural progression for a platform that was designed to be reliable --
while there have been attempts to graft a more versatile type system onto the
Erlang base language, the cleanest way forward seems to be a language purpose-
built for the task.

~~~
jeffdavis
"while there have been attempts to graft a more versatile type system onto the
Erlang base language, the cleanest way forward seems to be a language purpose-
built for the task."

Are you sure that's even possible? Erlang is fundamentally a dynamic system,
with hot code (re)loading, processes starting and stopping (possibly
crashing), and nodes attaching and detaching.

Moreover, the idea that a message can be sent to any PID seems fundamentally
at odds with type checking at compile time. You'd probably need to do
something more like channels.

Perhaps an ML-like type system can work with all of that, but it sounds like a
research problem.

~~~
NotableAlamode
Typing a the message-passing part of a language like Erlang is very much an
open research problem. I spoke about this at length with the session type
community. They are thinking about this, but it's at least a decade away.

~~~
platz
Isn't Akka planning to add types w/ typed akka? If they can pull that off some
subset of Erlang should be doable as well

~~~
mafribe
From a superficial reading I think what they are doing is quite simplistic.
Basically they want to provide typed channels, e.g. ActorRef[T] that only
accepts T messages. That's the easy part. What you really want is something
like type-based guarantees that a the interaction between actors cannot get
stuck. Achieving this is fraught with difficulties.

~~~
platz
no true scottsman? This reminds me of arguments against STM, which efforts
previously failed because they tried to enforce it across the whole system.
The way forward was to demarcate clearly which vars were in STM and which
weren't, and it is very useful - note doesn't solve the "hard theory cs"
formulation of STM.

Just because typed ActorRef aren't as hard as implementing this other property
which has some other "hard cs" property, does that really devaule the utility
of typed ActorRefs?

I admit I'm not sure exactly if 'the interaction between actors cannot get
stuck' property is something that is an existing pain point, or something that
would be introduced as a result of typed ActorRefs

~~~
mafribe
I didn't say it wasn't useful. It is. But it's checking essentially a
sequential property: a sequential actor is using a channel in a consistent
way. What e.g. the session type community is aiming at are properties of
concurrent computation, such as linear channel usage which depends on the
behaviour of multiple processes.

------
shadeless
Previous discussion: [0]

Talk on lowering the barrier to entry into Erlang ecosystem: [1] (slides: [2])

[0]
[https://news.ycombinator.com/item?id=7927849](https://news.ycombinator.com/item?id=7927849)
[1]
[https://www.youtube.com/watch?v=Djv4C9H9yz4](https://www.youtube.com/watch?v=Djv4C9H9yz4)
[2] [http://www.erlang-
factory.com/static/upload/media/1404379022...](http://www.erlang-
factory.com/static/upload/media/1404379022862808josevalimdavethomassf2014.pdf)

~~~
ghayes
I feel like Elixir in general goes a long way to lowering the barrier to using
BEAM and OTP.

~~~
GeorgeHahn
Do you think folks who are just getting started in the Erlang ecosystem would
be better to learn Elixir before Erlang?

~~~
RobertKerans
I'm at a basic level with Elixir (played around a little bit with Erlang
first), and so far I'd say definitely - the syntax choices seem very, very
good, and it's a pleasure to work with. I can now read Erlang code pretty
easily because of this, the concepts and structure are often the same, but
introduced in a far more understandable way, and it's felt a hell of a lot
smoother than going Erlang first - YMMV of course.

------
rdtsc
On a more lighthearted note, here is the "Erlang II The Movie" he made:

[https://www.youtube.com/watch?v=rRbY3TMUcgQ&x-yt-
ts=14219146...](https://www.youtube.com/watch?v=rRbY3TMUcgQ&x-yt-
ts=1421914688&x-yt-cl=84503534)

~~~
davidw
He's also the same guy behind other videos like "MongoDB is web scale!":
[https://www.youtube.com/channel/UCGHa3q15FmqB4D9yNlxrdKQ](https://www.youtube.com/channel/UCGHa3q15FmqB4D9yNlxrdKQ)

Time for a new one, I loved the Erlang sequel.

------
asa400
Warning: wall of text ahead.

My Erlang experience is admittedly hobbyist, and mostly as a consequence of
working my way through Fred's excellent
[http://learnyousomeerlang.com/](http://learnyousomeerlang.com/) and fooling
around with side projects.

As I see it, Erlang does a lot of cool stuff, at a semantic and systems level,
but utterly fails when it comes to things like approachability and marketing.
These topics are universal to all languages, so I feel that my experience as a
relative noob may help to illuminate the general outsider's perception.

First, the things it does well (taken from my admittedly tiny experience with
the system):

\- Simple language: I love that the surface area of the language really is not
that large.

\- Concurrency is built in to the core: unlike most languages, the concurrency
story is just "there". There isn't fuss or ceremony or terror around it. It
has been well thought out, and learning actors in their beautiful Erlang
implementation helped me take that knowledge elsewhere (mainly Scala, which
I'll come back to).

\- Legacy: you hear about the systems people have built with it and it just
blows your mind. The ability of the language and runtime to behave as a
cohesive, robust unit exists in few other places, if at all. The sort of
reliability and scale achieved as a result of this fact is incredible.

And not so well:

\- Beginner's story: The build tool was not immediately apparent, and it
seemed like the community had still not settled on one. The dependency story
seemed primitive and still not settled. The repl is pretty shit compared to
every other repl I've ever used: ruby, python, clojure, scala, etc. These are
obviously "subjective" perceptions, but I'm a fairly captive audience. I
_already wanted_ to learn Erlang, so these things will put me off much less
than someone who has to be sold on it.

\- General marketing: everyone keeps talking about phone switches and
Whatsapp, but I'm not writing software for a phone switch or Whatsapp. I know
Erlang works for other uses because I've seen some of the cool stuff the
community has done, but I don't think the rest of the world goes out of their
way to find awesome uses. It's still seen as this extremely narrow, focused
language, when actually people are using it for all sorts of things. A robust
general-purpose library ecosystem goes a long way to address this, as people
see a lib for their task and go, "ahh, a library for Foo! I can use Erlang!"

\- Reliability marketing: Reliability for most programmers is not "Nine 9's of
uptime". It's "how badly does this environment let me fuck up before
everything goes to hell?" They are effectively two sides of the same coin,
with one focused on a negative and the other on a positive. I see a huge,
neglected part of Erlang's potential sell in its inability to market itself as
letting you move faster and break more things. This doesn't mean you get to be
an idiot, but it effectively says to the programmer "I'm going to make it
harder for you to create a brittle system. Go on and try to build that
adventurous new feature, because I've got your back if shit hits the fan".

Related to these points is that there are other environments that get people
"most of the way there" without having to learn a totally alien ecosystem.
These are, namely, Go and Scala.

Erlangers will argue that with Go or Scala you may get some of the features of
Erlang, you don't get the whole package. This is true, but people don't think
this way. People think "does this sufficiently solve my problem, and does it
do so at a cost I can live with?" For people familiar with C, the cost of
doing a Go project is minimal. Basically, you get concurrency and GC taken
care of, while maintaining most of the syntax, semantics, deployment strategy,
and programming styles you already know.

With Scala, you get robustness, concurrency, and distributed computing in the
form of Akka (to a level that satisfies most people), while preserving access
to Java libraries.

Personally, Scala's arguments have been persuasive to me, which is why I'm
attempting to introduce it at work in lieu of Erlang. In addition to being
more approachable for my mostly Ruby and Javascript-programming colleagues
than Erlang (I concede that this point is definitely debatable), I can do
nearly goddamn anything in Scala: data analysis, NLP, network services,
webapps,number crunching, etc. I work mostly in data on a team that has a
large deployment of microservices, and for many questions we face I wouldn't
even know where to begin in Erlang. Scala, despite its flaws in terms of
binary compatibility, immaturity, type-snobbery, retains a relentlessly
practical, marketable feel, that I feel much more confident in bringing before
a group of programmers who know neither ecosystem.

If the Erlang community hopes to see the language and system achieve greater
general adoption, it has to learn to sell to the general case. It doesn't have
to win, but it has to make it easy for people to reap Erlang's amazing
features while not missing their Java, Ruby, or Python libs too much, or
taking too long to get started. Big ups to Elixir, as its community seems to
be working hard to address these problems, and hopefully greater-Erlang can
capitalize on the momentum.

~~~
IndianAstronaut
Thanks for this thoughtful post. I have been considering learning Erlang since
it has concurrency built in and I work with state systems already. I took a
look into its syntax and it was quite confusing and seemed like a huge
learning barrier. I will give scala and go another look.

~~~
klibertp
The syntax is unfamiliar to you, which is why you found it confusing. In
reality Erlang syntax is very simple and consistent, here you have most of it:
[http://erlang.org/doc/reference_manual/expressions.html](http://erlang.org/doc/reference_manual/expressions.html)

I don't understand people who refuse to learn unfamiliar syntaxes at all. A
syntax is only bad if it matches semantics poorly, for example in JavaScript
you create functions very often, for various purposes, yet syntax for this is
rather verbose, which may hurt readability by obscuring what's really going
on. In case of Erlang the syntax supports the semantics quite well. For
example, sending async messages between processes is central part of the
language and accordingly has lightweight syntax, essentially: "Target !
SomeMessage". It's also highly consistent, for example guard patterns in
functions have exactly the same syntax as guards in "if" expressions;
destructuring has the same syntax no matter where it's done, in funcion
definition, case statement or inline with "=" operator. And so on.

In general you should try to understand the syntax and underlying semantics
before saying anything about it.

