
Why Erlang?  - hukl
http://smyck.net/2012/04/22/why-erlang/
======
silentbicycle
A lot of intros to Erlang miss an important point: Erlang is about _fault
tolerance_ , not concurrency. The concurrency is a means to an end -- if your
systems has to survive process crashes, hardware failures, and so on, it needs
to have multiple components that can supervise and restart each other. Unlike
(say) node.js, in Erlang, error handling is priority #1. Its ability to juggle
lots of concurrent connections is just a consequence of its priority on
localizing errors.

Also, Erlang tries to address many failure cases that other
languages/platforms do not; this isn't free. It's often a good trade-off
(making systems resilient after the fact can be quite an undertaking), but
worth noting.

------
ZephyrP
I think this is a great article but misses some of what I think are the most
essential points of what makes Erlang great.

Superficially, Erlang is Actor Model for functionalists. I could go on about
the various advantages this model provides, but as other posters have so
eruditely pointed out, MPI provides the same abstract framework for dealing
with the problems that actors are intended to solve.

I'm not a professional erlang developer, but I've based and written a new
NoSQL database thats intended to store billions of records in Erlang,
altogether clocking in at less than 1000 lines of code, and after this
experience, I can safely say that I will never try to build distributed apps,
save some niche cases, in another language (even Haskell).

Here's what stands out about Erlang to me, in contract to comparable options.

Firstly, HiPE and BEAM may be the most advanced virtual machine systems in the
world. People working with JVM will claim this an exaggeration, but in terms
of reliability and speed, my experience with HiPE is unmatched.

Secondly, and perhaps more importantly, OTP.

Open Telephony Platform is the single best collected library for dealing with
various problems that I have ever seen. The Generics (gen_server, gen_fsm,
etc.) are a quick, fast and easy solution to problems and edge cases that
would bog down even the best MPI developer. For example, dealing with internal
state as a finite state machine is not new, but it's not nearly as popular as
it should be, perhaps to this end it's apt to say that Erlang does for
parallelism and distribution what Ruby on Rails did for web development -- It
forces you to make intelligent decisions.

The systems responsible for controlling emergency services, global telecom
infrastructure, many large MMOs, and countless other applications _are_
Erlang. If you trust 911, you can trust Erlang.

I could go on, Hot code loading while old processes still depend on usable
code? Built in failover? Function takeover? Automatic workload offloading?
Good luck if it's not Erlang.

~~~
davidw
> Firstly, HiPE and BEAM may be the most advanced virtual machine systems in
> the world. People working with JVM will claim this an exaggeration, but in
> terms of reliability and speed, my experience with HiPE is unmatched.

Reliability, maybe, but these benchmarks disagree with 'speed':

[http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-fastest.php)

It's not _bad_ \- it beats a lot of dynamic languages - but it's not great
either. Go and Javascript V8 both beat it.

~~~
davidw
Uh, is anything I said here actually inaccurate, or is somebody just
downvoting because I said something "bad" about Erlang (which jlouis actually
confirms...) ?

I hate this kind of mentality. If you can't look at things honestly, you'll
never improve your favorite language(s).

~~~
jlouis
I don't think you have said anything wrong, for the record. Go outperforms
Erlang, mainly because it is a compiled language. V8 is a JIT-compiler (and it
doesn't even interpret per se). In other words, those two systems are usually
much faster than the BEAM VM when it comes to raw CPU bound computation.

HiPE does help a lot, but even with HiPE you can't easily beat a language with
a static type system like Go: You have much less data to shove around when
there are no type tags needed on most data.

------
boothead
Can anyone comment on writing erlang style apps in Haskell?

Haskell appears to have many of the required ingredients: Cheap multi
threading, immutability and the Cloud Haskell[1] framework, with the added
benefits of speed and the awesome type system.

I currently use eventlet and ZeroMQ in python to emulate a similar (and
probably crappier) style of writing message passing concurrency apps. With the
addition of protocol buffers this type of architecture is easily applicable to
a multi language set up. I'd be very interested to see what others are doing.

Has anyone who's used erlang tried playing with Haskell in the same role?

[1] <https://github.com/jepst/CloudHaskell>

~~~
jlouis
Yep, see my Combinatorrent and eTorrent projects, respectively. The long story
short is here:

[http://jlouisramblings.blogspot.com/2010/04/haskell-vs-
erlan...](http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlang-for-
bittorent-clients.html)

~~~
boothead
Thanks for the link, I remember reading it a while back. Have you played with
the cloud haskell stuff at all? I seems you were able to achieve most of what
you wanted with STM channels for combinatorrent - do you think that the
presence of cloud haskell might have made any difference?

~~~
jlouis
Cloud Haskell came after my work, so I do not know how it fares. I remember
that I saw it and thought that there were neat ideas in there.

My guess is that it would simplify the amount of work I had to do in code
since CH would subsume many of my lines.

------
revertts
What I gather from the slides:

1\. server loads the data from S3 on start (sessions are sticky to a
particular server)

2\. user data gets mutated on that server for the lifetime of the session

3\. the data gets written back to S3 on session end

How are failures handled in 2? If a box goes down, do you not only lose the
open connections but also any data that has been changed in that session? If
these are game sessions it seems like they'll be long-lived; do you
periodically dump back to S3?

------
Scorponok
I've been curious about this for a while: If you can do concurrent processing
so easily by message passing, why not just write Java or C++ that just passes
messages around instead of sharing state? That way you don't have to learn a
whole new programming language to do it.

~~~
ryanmolden
You can do that, but as far as I know Erlang (not far, mind you) it takes care
of a ton of details for you. For instance to send a message to another actor,
whether they are on you machine or a remote machine you just need a PID
(process identifier, an Erlang id concept similar to, but not the same as an
OS level PID). In C++ you would either need to deal with local/remote
differences in message transport (ignoring the non-trivial nature of
serializing arbitrary types in C++) or create an abstraction that would do so
on your behalf. Second, in Erlang all actors have their own heaps, so their
local data is spatially close in memory by definition making actors NUMA/cache
friendly (assuming the runtime is "doing it right") heap allocated data passed
between actors in C++ wouldn't have that attribute by default (again, you
could make it so with some effort, but it certainly isn't free). Third actors
in Erlang don't use full OS level threads, so the overhead of spawning say 10k
of them is not the overhead of spawning 10k C++ threads (also ignoring that
C++ really only acknowledged the existence of threads in C++11). These are a
few issues/benefits, but as I said you could do all of this in any language
mostly, but in Erlang a lot of the gross/tricky details are already handled
for you.

~~~
jimbokun
In other words, it would require Greenspunning Erlang.

------
luriel
On a related note, I have heard of quite a few game companies that are using
Go for their server side code.

~~~
teamonkey
That's quite interesting. I'd like to know what kind of games. Care to name
names?

~~~
Jare
The server code for AirMech by Carbon Games is written in Go: see
<http://carbongames.com/> Basically, a modern Herzog Zwei.

------
namidark
I'm curious to know what type of CPU & Memory utilization there was on the
ruby backends vs the erlang backends between the two games

~~~
ConstantineXVI
He states that the Erlang server only needed a single box vs. the 80-200 for
the Ruby; I'd wager the Erlang is dramatically lower in terms of resources
consumed (or at least much more efficient)

------
halayli
In lthread, a coroutine lib, (<http://github.com/halayli/lthread>) you can
make blocking calls inside coroutines. It gives you the lightness of event-
driven, the advantages of threads, and the simplicity of sequential
statements. And it can scale over cores.

~~~
jerf
Remember, Erlang scales between machines.

Erlang's actually all about reliability. It's the secret decoder ring to its
design, not the actor model or message passing, which serve as the ways it
gets to reliability. (Even to some extent its syntax. Excepting comma-period-
semicolon which is just dumb.) And one of the principles of Erlang is that you
don't have reliability when you are running on only one set of computer
hardware.

~~~
halayli
lthread allows you to do so by message passing.

------
nirvana
Frankly, I'm surprised (but I shouldn't be) that so many people are desperate
for an alternative to Erlang. Going so far as to try to pretend that libraries
bolted on to other languages give you the same thing at lower cost. This is
impossible, and you'd understand that if you understood what erlang does.

Stop that, right now. You're supposed to be hackers. New technology isn't
supposed to scare you this much.

Erlang doesn't use the C style syntax. BIG WHOOP. Yeah, it looks "weird" at
first but don't be scared off by it.

You can't get the fault tolerance (and consequential scalability) of erlang in
any other language/platform. Period. Full Stop. It simply doesn't exist.

Yeah, theoretically, one could build it with some low level language like C.
You whipping up crappy C++ code using an "actor" library is not the same
thing, by a long shot.

So, unless you want to spend 20 years reinventing the wheel, why not just use
the wheel. Yeah, I know its round and you're used to square.

I promise you that you'll really enjoy the much smoother ride.

Don't be a blub programmer. Learning erlang takes you about 2 weeks. The
syntax is perfectly fathomable once you put in those two weeks.

But be serious about it. Do a chapter each night from the armstrong book.

This really is one of those languages that separates the hackers from the
hacks. Not because its difficult, but because the hackers are not scared of
it, while the hacks are.

Seriously. Stop rationalizing.

~~~
sparkie
While I wouldn't disagree with your points, I think you've chosen a fairly
narrow view of reasons people might want an alternative to erlang.

An obvious case you've omitted, is that people already have existing codebases
written in other languages, and rewriting them all in erlang is not an option.
Attaching an actor library to "X" language can give us many of the features
offered by erlang with our existing codebase, and allow us to continue using
our existing skills and paradigms.

Erlang does an excellent job at solving certain issues, but it's lacking in
many other areas that "X" might do a better job of. If my project needs both
the fault tolerance and concurrency of erlang, and feature "A" which language
"X" is good at, but erlang not so good at, then choosing erlang all the time
might not be the right solution.

I'm personally a fan of polyglot programming. We should pick the most suitable
languages for each task, then we wouldn't need to keep re-inventing
programming languages and libraries to emulate other languages. It's quite an
idealistic view, but there's certainly ways we can improve the
interoperability between languages, including erlang's - which is quite
limited so far.

An example of such approach is the (now discontinued) Axum project from
Microsoft Research. It offered many of the ideas of Erlang, but built onto the
.NET framework and largely compatible with existing code. Axum could call, and
could even contain almost any C# code inside it, although it was a restricted
version of C# which had isolated states, and no static variables - something
that high standard codebases omit anyway, regardless of the whether language
allows it, because it's been known good practice for a long time that shared
state causes problems.

The Actor Model existed long before Erlang, and will feature in many other
languages other than it - whether or not they are successful is a different
matter, but programming language designers would be wise to have a good
knowledge of Erlang, and many other languages, so they're not re-inventing the
wheel badly. Concurrency and fault tolerance should be considered from the
start.

I personally think we can do better than Erlang - or at least offer the same
without sacrificing every other paradigm to achieve the aims of erlang. (And
Haskell will probably be the language to better it).

~~~
silentbicycle
Since when do you have to rewrite everything in Erlang? Erlang is happy to
call out to code in C (or whatever) via ports, which are a way for Erlang to
run untrusted code in isolation and restart it when it crashes. Unlike (say)
Ruby or Python, buggy C libraries can't bring the whole system down in Erlang.

------
andyl
Erlang is indeed impressive. But there is a big learning curve (at least for
me!) and a whole new tool-set to support. It would be great if a Ruby/ZeroMQ
based framework modelled on Erlang became widely adopted.

~~~
masklinn
Most of the learning curve really is OTP. And as with Cocoa, the only way to
skip those is to reinvent them, or not even reach an understanding of the
problem they're solving.

I'd expect an equivalent toolset on a different platform to have an equivalent
learning curve if it existed at all.

