

What's all this fuss about Erlang? (2007) - dlcmh
https://pragprog.com/articles/erlang

======
renox
> Here’s the good news for Erlang programmers: Your Erlang program should just
> run N times faster on an N core processor

I hate this kind of marketing trick.

So let me add: And here's the bad news, your Erlang program can be much slower
than a C program on one core: for example in the alioth 'benchmarks' Erlang
run between 3X and 30X slower than a C program on one core (
[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=hipe&lang2=gcc&data=u64)
) so you may have to throw MANY core at it before the Erlang program is faster
than the C program.

So beware! YMMV.

That said, I hope that Elixir will improve Erlang's adoption as the high
availability feature are the big deal IMHO.

~~~
segmondy
it's no marketing trick. Here's the reality. Let's suppose you have a C
program that can run 10x faster than an equivalent erlang program, and your
erlang program scales by the core, then you need 10 cores to have your erlang
program keep up with C. The idea is that it's far easier to scale up by cores
in Erlang than in C. Parallelization is far harder with C than in Erlang, so
you might find that even tho your C program runs 10x faster, given 1000 cores,
you won't be able to scale it without a complete rewrite, whereas you can take
the same erlang problem and with minimal modification have it run 100x faster
than the C equivalent on your thousand cores.

~~~
jerf
Even Erlang can't promise linear scaling forever, because nothing can. We call
things that can linearly scale indefinitely "embarrassingly parallel", and the
point of the first word in that phrase is that it's so easy that it's
embarrassing to claim to be good at it, because it's easy. So for the class of
problems that Erlang _can_ scale like that, well, so could C.

It's what I consider to be a core problem with the dynamic languages, which
Erlang technically is... you take such a single-core hit that it's essentially
impossible to gain the performance back on multithreading. It's one of the
reasons to be taking a serious look at Go; while it is far from the first
"modern threading" system, it's _one of_ the first to be combined with simple
near-C performance. (Emphasis carefully chosen.) Java arguably has some
solutions though I've not yet taken a close look at Akka performance. Erlang
doesn't have near-C performance. Haskell can only get near-C performance with
a lot of work and care. (They're still working on it, but it's still non-
trivial.) The scripting languages are laughably far away from near-C
performance and you take such a performance hit that it doesn't matter how
easy they make multiprocessing after that.

I've still used Erlang for things that are truly IO bound. It's great for that
and a very solid VM. But don't fool yourself into thinking Erlang is a
performance solution for anything else. (And I find people yell "IO bound!" a
bit too readily sometimes. That's really in the class of things you should
profile before being sure.)

~~~
nivertech

        Erlang is optimized for latency.
        OpenCL is optimized for t-put.
        Everything else (including C) is in between.

~~~
renox
> Erlang is optimized for latency.

Too short: for latency __with multiple simultaneous users __. If you have a
'one shot' program or one user at a time, you'll probably get better latency
with C than with Erlang.

~~~
nivertech
More exactly latency of switching between concurrent activities, which might
be handling user sessions, but might be something else too.

------
damienkatz
Former serious Erlanger here. Lots of comments about performance and scaling
in this thread. If you are writing a system for internal use, it's simple
scalability and robustness make Erlang an excellent choice. Engineers are
expensive, machines are cheap.

However, if you are writing something that needs _massive_ scalability, the
number of machines necessary and the management of it all starts to eclipse
engineering cost. Then you need to drop down to a lower level language, or at
least something more runtime optimized (like java) for the heavy lifting. Then
the costs and frustration of debugging across two languages becomes
burdensome.

If you are building a competitive commercial product that will be deployed to
many customers, the economics start to swing away from Erlang. Customers don't
care you needed 1/3 the engineers and testing (or whatever) to get it working.
They don't care about how much time and money you saved writing it. They care
their EC2 bill is low, or the number of machines in their data center is
reduced. A competitor who writes in C might have longer time to market, but
they will clobber you when customers see they need 1/4 the machines to support
the same workload.

Erlang will NEVER be fast. The reason has little to do with the language
semantics, and everything to do with it's lack of widespread adoption and
therefore lack investment in compilers, runtimes and debugging tools, etc.
It's slow because the syntax is ugly and thwarts adoption. If you are a badass
VM/complier/JIT/etc engineer, you'll apply your skills to something like
Javascript, Java, Python, Ruby, etc and affect a much larger audience.

Also the lack of adoption makes Erlang a hard sell in a corporate
environments. Sure you might get something up and running much faster, but if
your erlangers leave, finding replacements engineers to maintain the system
will be tough. I've lived this.

I wish I were wrong about it, but 9 years of watching Erlang on the verge of
mainstream has jaded me.

------
unterstrom
I really like his minimalistic writing style. Wish other authors (especially
americans) would follow his example. Not every simple fact needs an anecdote.

~~~
goshx
This! Some people love to write a thousand words to give you 10 words of
actual information.

------
kornakiewicz
Quick question: If you recommend to start learning Erlang now, it's better to
play with normal one (I actually don't like syntax since I'm used to
semicolons and other C-influenced stuff) or Elixir, which looks pretty neat?

~~~
loxs
Both. Elixir is the future, but mostly, you write the same thing with a
different (better) syntax. No way you will write Elixir without understanding
Erlang

~~~
coldtea
Is that so, or is that old wives tales? Because in most "layered" languages,
you can go quite far without understanding the base language, as long as you
understand the semantics of the higher level language.

I don't need to know Java to write Scala for example -- I just need to know
the relevant semantics of Scala's object system and interoperability.

~~~
thisishugo
The semantics of Elixir are a superset of the semantics of Erlang, so by
learning the former, you're learning the latter anyway. Plus, you'll be
calling a _lot_ of Erlang libraries from Elixir, so understanding how Erlang
works is extremely beneficial to using Elixir.

------
dasmithii
Was Erlang designed in light of any ancestor languages? Or is it fairly
original - create from scratch?

I'm interested in the language design process.

~~~
rheese-archer
You can read about it in detail in Joe Armstrong's master thesis. I would
recommend it be read from cover to cover:

[http://www.erlang.org/download/armstrong_thesis_2003.pdf](http://www.erlang.org/download/armstrong_thesis_2003.pdf)

~~~
signa11
also, might consider reading this seminal paper from jim-gray (tandem
computers) "Why Do Computers Stop and What Can Be Done About It?"
[http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf](http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)

edit: if you look at the timelines, the thesis was presented in 2003, and is
the result of stuff that started off in 1981. pretty cool (fwiw)

------
davidw
There was some hype about Erlang 6/7 years ago, too, but it didn't seem to be
enough to give it much momentum:

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

[http://lambda-the-ultimate.org/node/2386](http://lambda-the-
ultimate.org/node/2386)

~~~
jhancock
Seems to me erlang adoption has been chugging along just fine (with or without
HN posts). There are some high-profile startups using erlang: WhatsApp and I
think Facebook Chat is/was.

There has been progress in cleaning up syntax, library and package management
cruft that have helped ease adoption. Elixir (a new lang built on erlang)
seems to be coming along well.

For most types of webapps, erlang has all the batteries included. The problem
is that for many mainstream types of webapps, getting v1 out the door quickly
in Rails/Django works well. I think that may be part of the adoption
problem...if the problem domain doesn't clearly require erlang to get v1 out
the door, many will use Rails/Django and never look back.

~~~
davidw
Yeah, it's slowly and steadily coming along. But it seemed at a certain point
a few years back that there were people beating the hype drum, and nothing
much seems to have come of it: the slow steady growth continues.

------
bsaul
The line "erlang has no mutable data structure" made me think about something
:

Couldn't you imagine a language with data structure that are mutable _from
within a same single thread only_ and requires message passing _when
communicating between threads_ ?

Now that i think of it, I wonder if golang isn't doing just that.

~~~
rssaddict
I'm not too clear on the details since I don't know the language, but I
_think_ that Rust's ([http://www.rust-lang.org/](http://www.rust-lang.org/))
concept of "ownership" does something very similar to what you're suggesting.

