
Why Erlang matters - petrohi
http://petrohi.me/post/35644212001/why-erlang-matters
======
rvirding
Every time I read something about the weird Erlang syntax I get so tired and
try and tell myself not to get into the discussion, it's not worth the effort,
some people will never just never learn, etc. But sometimes I can't help
myself. So some of my thoughts on this:

\- Syntax is the easiest part of learning a language. It's all written down
and its just a RTFM. And yes, I have written a lot of C and lisp and prolog
and erlang and ... and I never have problems with the syntax.

\- If people worry so much about the syntax what happens when they get to the
semantics?

\- Seriously, why would you want to Erlang to have similar syntax to a
language with different semantics? In my view that would be asking for
trouble. I think one reason why I haven't had trouble with mixing languages is
that both the syntax and the semantics are different. C looks like and behaves
like C while Erlang looks like and behaves like Erlang.

\- The erlang syntax is actually very simple, much simpler than the languages
you would like it to look like.

I will now stop before I say something nasty.

I liked the blog.

~~~
petrohi
When semantics are very different and syntax tries to pretend they aren't to
create false familiarity this will lead to some very painful brain-splits
later on. I can assert from my own experience with alternating the use of =
between Erlang and C++.

Glad you liked the blog.

~~~
rvirding
Yes, in retrospect using = was probably not a very good choice. I will admit
some things in Erlang didn't receive much thought before being added while to
some things we gave a lot thought; for example the language/systems basic
properties and the semantics of concurrency, message passing and error
handling.

------
dschiptsov
It is not just "matters". It is a deeply-researched and well-engineered
explicitly concurrent programming language by smart and passionate people. It
is a very rare example of first-class project, compared to the common
nonsense, like Java or, god forbid, NodeJS.)

If it is not that popular (which is rather good) it is not a language's fault.
It is due to inability to acquire and maintain an appropriate mindset.

btw, there is a nice lecture -
[http://www.youtube.com/results?search_query=Erlang%2BJoe%2BA...](http://www.youtube.com/results?search_query=Erlang%2BJoe%2BArmstrong)

~~~
shtylman
This reminds me of a great quote.

"There are only two kinds of languages: the ones people complain about and the
ones nobody uses" -stroustrup

If you have to write about how your language matters, you have already missed
the point. If it mattered, people would be using it.

~~~
derdesign
I bet you or a friend of yours chats on facebook[1] or Watsapp[2]...

[1] [http://www.erlang-
factory.com/upload/presentations/31/Eugene...](http://www.erlang-
factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)

[2] [http://blog.whatsapp.com/index.php/2012/01/1-million-is-
so-2...](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/)

------
jfaucett
People are always asking what is a good HN article, I'd say this is, great
links to research that backs up many of the assertions.

"Erlang matters today because it demonstrates how these semantics can be
elegantly packaged in one language, execution model and virtual machine." I
think yes, in a theoretical sense this is absolutely true. The question is why
is it not a language in widespread practical use?

~~~
klibertp
> The question is why is it not a language in widespread practical use?

1\. It kind of is, I think RabbitMQ, CouchDB and Riak are doing ok, for
example.

2\. Both syntax and semantics are sufficiently different from "industry
standard" to be a hurdle for majority of people... I'm being told. I don't
understand this; the more different the language is the more interesting it
seems to me and the more happy I am to learn it[1], but I heard this argument
enough times to accept it as (sad) reality.

[1] And there is still so many of them to learn! Take a look at any one
RosettaCode page (<http://rosettacode.org/wiki/Y_combinator>) if you don't
believe me :)

~~~
codewright
RabbitMQ has some pretty serious limitations related to it being implemented
on Erlang that keep it pretty strictly in the realm of being a message queue
rather than a generic queue.

CouchDB is more C++ than Erlang these days, bad example. It hasn't been mostly
Erlang for a really long time. Erlang basically only does the clustering
behavior, which is something Zookeeper et al. do already.

Riak is the only solid example out of those you listed, and its known for
having poor raw performance, excellent availability, easy clustering, and
awful usability.

~~~
calibraxis
> RabbitMQ has some pretty serious limitations related to it being implemented
> on Erlang that keep it pretty strictly in the realm of being a message queue
> rather than a generic queue.

Interesting, where can I learn more about this claim? What are the
incompatible facets of a generic queue and Erlang? What is an example of these
generic queues (or if it's only an ideal, what are its characteristics)?

~~~
codewright
Just don't use it for big, long-lived work queues and you'll be fine.

If the queue gets badly backed up, you're probably fucked.

Larger, longer-lived work queues are really more of a Hadoop thing, not an in-
memory queue thing.

~~~
klibertp
I got curious and googled a bit, here's what I found:
[http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-
fo...](http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-for-durable-
messaging-with-good-query-features)

Where the first answer states that: "RabbitMQ presumes that consumers are
mostly online, and any messages "in wait" (persistent or not) are held
opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) _would fall over_ if your
consumers were too slow, but now it's robust for online and batch consumers -
but clearly large amounts of persistent messages sitting in the broker was not
the main design case for AMQP in general."

(It's contrasted with Kafka, which is "designed for holding and distributing
large volumes of messages")

Still, I see no reason why you say that it's Erlang that causes this?

~~~
codewright
People often use Erlang primarily for the memory model. Pure in-memory didn't
work for our use-case.

You can implement a queue that works better for batch work in Erlang, it's
just that it'd be closer to a data store.

------
rustc
On a related note, has anyone tried Elixir[1], which is a Ruby-like language
that runs on the Erlang VM. If so, what project was that? how was your
experience?

[1] <http://elixir-lang.org/>

~~~
rubyrescue
Inaka does a lot of Erlang. We really like Elixir and we're excited about it.
It's still early but it gives you the runtime environment of Erlang with the
syntax of Ruby. It has a few very active, passionate folks behind it which
will cause it to continue to grow.

------
millerm
I was just put on a new Erang/OTP project at work and will be working on it
for the next 9 months or so. I'm currently on a "ramp up sprint" to get to
learn the language, tools and libraries, then we will move on to development.
I'm really enjoying the language. OTP is quite elegant and just awesome. Sure,
there are a few annoying things in the language that I have already read about
on the Net/here but, I can look past those paper cuts. I've been really
diggin' Lisp (Clojure, Racket, CL and Scheme) and other functional languages
and have been enjoying the concepts so much. I've really become enamored with
functional languages and really don't want to write another lick of Java. I'll
keep the Objective-C because I have to, you know why. I am not dissin' (crap,
I used that word) Java. But, it is nice to be given the opportunity to think
differently (damn, another unoriginal phrase).

Anyway, just giving a shout out to Erlang as I am finding the platform to be
very interesting and that makes the day go by much better.

~~~
petrohi
Great to see more adoption for Erlang/OTP. The return on investment is clearly
there for us at connect.me. We're implementing our backend and API in
Erlang/OTP.

Can you share what type of application you will be working on?

------
commentzorro
Erlang's been fine for showing us what's good and what's bad. But most of all,
Erlang allows us to take the good parts and move them to a "friendlier"
language when the time comes.

~~~
hvs
What do you mean by "Erlang allows us to take the good parts and move them to
a 'friendlier' language when the time comes"? Is there something I don't know
about porting code from Erlang to other languages? (Not being snarky,
genuinely curious.)

~~~
commentzorro
Keep the idea of lightweight processes, crash at will, message passing, etc.
and move these techniques into other languages so we don't have the awkward
syntax.

~~~
klibertp
Aaaargh :(

Why, why syntax does have to matter? I thought it matters too, at first, but
after sixth or so language I noticed the feeling of importance of syntax
vanishing. Now I find good support in my editor much more important than
syntax.

(Edit: and "you don't need editor support if you have good syntax" doesn't
seem true to me either)

~~~
juan_juarez
That's the point. A great many programmers learn one or two languages over the
course of their lifetimes - look at all of the career Java and C# programmers.

------
rartichoke
Would it be safe to say Scala with the Akka lib offers the same robustness and
distributed scalability as Erlang?

Erlang is using the actor model and so is Akka.

I really want to learn one or the other as a goto functional language.

I keep looking at sites like Netflix, Twitter and Foursquare. Those seem to be
sites running on either Java or Scala.

Why would they pick that instead of Erlang?

~~~
SoftwareMaven
Pragmatism. It is easier to find JVM-knowledgeable people than to find BEAM-
knowledgeable people.

The actor model isn't the only aspect that gives Erlang its robustness. In
fact, far more important is its supervisory model, which goes as deep as you
want it and can supervise across system boundaries.

I keep waiting for the language that learns these lessons from Erlang with a
happier syntax, but I have yet to find it.

~~~
ericmoritz
Akka does have supervisors. If you find Scala to be a happier syntax than
Erlang (eye of the beholder), than Akka is worth looking into. It appears to
be directly inspired by OTP and Erlang's "let it crash" ideology.

------
chaitanyapandit
I had the syntax fear when I started learning Erlang, but I think the syntax
is tailored to the language itself: \- Recursion \- Pattern Matching

The problem occurs when you try to translate the Erlang syntax to the language
of your choice, which isn't the right approach. C, and Java don't use pattern
matching, so naturally their syntax is not designed for it.

Maybe one should write a small program to demonstrate the key functionalities
of Erlang, like write a TCP packet decoder etc, then try doing the same in
your prefereed language and then see what makes sense.

------
rossjudson
What's missing from your article is a demonstration or theory that outlines
how transmission over CPU-interconnects of immutable messages as blocks of
memory outperforms the cache coherence algorithms already in place.

Immutable message transmission has no way to say "I already know about this
message; don't send it again."

Most of the good characteristics of Erlang that you describe are achievable in
other languages.

So what I'm asking is, by what concrete mechanism does immutable message
passing outperform cache coherence?

~~~
seiji
It's not about raw performance. It's about getting shit done and keeping shit
highly available. In large systems, shared data isn't mentally optimal to work
with (see: every multithreaded program with shared data segfaulting for some
unknown reason this very second).

We can always drop down to C or asm to make ultra-shared data structures with
minimal overhead. We could always do that. But people end up wanting to spend
their precious lives making a difference in the world and not checking the
return value of malloc thirty times per day.

~~~
derdesign
> But people end up wanting to spend their precious lives making a difference
> in the world and not checking the return value of malloc thirty times per
> day

So true!

------
dsiemon
<http://dl.acm.org/citation.cfm?id=2209269>

~~~
petrohi
Great article. I've been inaccurate in the blog saying that cache coherence
will or should go away. What I mean is that ugly (non-scalable) effects of
cache coherence as implemented by today's vendors can be relieved by Erlang VM
to some degree. In the comment above [1] I say "It can also scale well if
sniffing is not a broadcast". Your article is to the point by addressing
exactly this issue with tracking of sharers.

[1] <http://news.ycombinator.com/item?id=4780706>

------
z3phyr
How does Erlang compare to Haskell?

~~~
Fixnum
Until recently, Haskell didn't have an equivalent to Erlang's built-in support
for distributed computing, but the new Cloud Haskell library
(<http://www.haskell.org/haskellwiki/Cloud_Haskell>) provides message-passing
concurrency with a semantics very close to that of Erlang (but with more
support for type-safety).

I'm not sure Cloud Haskell is ready to dethrone Erlang (and the OTP framework,
and tooling for debugging distributed processes, and special VM features, ...)
for high-reliability distributed computing _today_ , but Haskell and its
libraries are evolving with absurd speed and the Cloud Haskell ecosystem could
certainly be competitive with Erlang in the near future. Haskell can certainly
be used to write high-performance network applications (e.g., Mighttpd, Warp),
so it's surely only a matter of time ...

~~~
z3phyr
+1 to Cloud Haskell.

But, they should change its name so that it sounds like a library and not
another language dilect. :)

Judging by its name, I thought that its a new haskell dilect ;)

------
pla3rhat3r
How come there are no Erlang articles start with, "this new technology is
GREAT!" Oh yeah. Nevermind.

~~~
xnld
But... Erlang isn't new technology.

