Where is Erlang used and why?

Question

I would like to know a list of the most common application/websites/solutions where Erlang is used, successfully or not.

Explaining why it is used into a specific solution instead of others programming languages would be very much appreciated, too.

Listing BAD Erlang case studies (cases in which Erlang is misused) it would be interesting, as well.

Solution 1

From Programming Erlang:

alt text http://bks8.books.google.com/books?id=Qr_WuvfTSpEC&printsec=frontcover&img=1&zoom=5&sig=ACfU3U2F4YY4KqO0vCuZ4WEZjdE2yFFvvg

Many companies are using Erlang in their production systems:

• Amazon uses Erlang to implement SimpleDB, providing database services as a part of the Amazon Elastic Compute Cloud (EC2).

• Yahoo! uses it in its social bookmarking service, Delicious, which has more than 5 million users and 150 million bookmarked URLs.

• Facebook uses Erlang to power the backend of its chat service, handling more than 100 million active users.

• WhatsApp uses Erlang to run messaging servers, achieving up to 2 million connected users per server.

• T-Mobile uses Erlang in its SMS and authentication systems.

• Motorola is using Erlang in call processing products in the public-safety industry.

• Ericsson uses Erlang in its support nodes, used in GPRS and 3G mobile networks worldwide.

The most popular open source Erlang applications include the following:

• The 3D subdivision modeler Wings 3D, used to model and texture polygon meshes.

• The Ejabberd system, which provides an Extensible Messaging and Presence Protocol (XMPP) based instant messaging (IM) application server.

• The CouchDB “schema-less” document-oriented database, providing scalability across multicore and multiserver clusters.

• The MochiWeb library that provides support for building lightweight HTTP servers. It is used to power services such as MochiBot and MochiAds, which serve dynamically generated content to millions of viewers daily.

• RabbitMQ, an AMQP messaging protocol implementation. AMQP is an emerging standard for high-performance enterprise messaging.

Solution 2

ejabberd is one of the most well know erlang application and the one I learnt erlang with.

I think it's the one of most interesting project for learning erlang because it is really building on erlang's strength. (However some will argue that it's not OTP, but don't worry there's still a trove of great code inside...)

Why ?

An XMPP server (like ejabberd) can be seen as a high level router, routing messages between end users. Of course there are other features, but this is the most important aspect of an instant messaging server. It has to route many messages simultaneously, and handle many a lot of TCP/IP connections.

So we have 2 features:

• handle many connections
• route messages given some aspects of the message

These are examples where erlang shines.

handle many connections

It is very easy to build scalable non-blocking TCP/IP servers with erlang. In fact, it was designed to solve this problem. And given it can spawn hundreds of thousand of processes (and not threads, it's a share-nothing approach, which is simpler to design), ejabberd is designed as a set of erlang processes (which can be distributed over several servers) :

• client connection process
• router process
• chatroom process
• server to server processes

All of them exchanging messages.

route messages given some aspects of the message

Another very lovable feature of erlang is pattern matching. It is used throughout the language.

For instance, in the following :

access(moderator, _Config)->  rw;
access(participant, _Config)->  rw;
access(visitor, #config{type="public"})->  r;
access(visitor, #config{type="public_rw"})->  rw;
access(_User,_Config)->  none.

That's 5 different versions of the access function. Erlang will select the most appropriate version given the arguments received. (Config is a structure of type #config which has a type attribute).

That means it is very easy and much clearer than chaining if/else or switch/case to make business rules.

To wrap up

Writing scalable servers, that's the whole point of erlang. Everything is designed it making this easy. On the two previous features, I'd add :

• hot code upgrade
• mnesia, distributed relational database (included in the base distribution)
• mochiweb, on which most http erlang servers are built on
• binary support (decoding and encoding binary protocol easy as ever)
• a great community with great open source projects (ejabberd, couchdb but also webmachine, riak and a slew of library very easy to embed)

Fewer LOCs

There is also this article from Richard Jones. He rewrote an application from C++ to erlang: 75% fewer lines in erlang.

Solution 3

The list of most common applications for Erlang as been covered (CouchDb, ejabberd, RabbitMQ etc) but I would like to contribute the following.

The reason why it is used in these applications comes from the core strength of Erlang: managing application availability.

Erlang was built from ground up for the telco environment requiring that systems meet at least 5x9's availability (99.999% yearly up-time). This figure doesn't leave much room for downtime during a year! For this reason primarily, Erlang comes loaded with the following features (non-exhaustive):

• Horizontal scalability (ability to distribute jobs across machine boundaries easily through seamless intra & inter machine communications). The built-in database (Mnesia) is also distributed by nature.

• Vertical scalability (ability to distribute jobs across processing resources on the same machine): SMP is handled natively.

• Code Hot-Swapping: the ability to update/upgrade code live during operations

• Asynchronous: the real world is async so Erlang was built to account for this basic nature. One feature that contributes to this requirement: Erlang's "free" processes (>32000 can run concurrently).

• Supervision: many different strategies for process supervision with restart strategies, thresholds etc. Helps recover from corner-cases/overloading more easily whilst still maintaining traces of the problems for later trouble-shooting, post-mortem analysis etc.

• Resource Management: scheduling strategies, resource monitoring etc. Note that the default process scheduler operates with O(1) scaling.

• Live debugging: the ability to "log" into live nodes at will helps trouble-shooting activities. Debugging can be undertaken live with full access to any process' running state. Also the built-in error reporting tools are very useful (but sometimes somewhat awkward to use).

Of course I could talk about its functional roots but this aspect is somewhat orthogonal to the main goal (high availability). The main component of the functional nature which contributes generously to the target goal is, IMO: "share nothing". This characteristic helps contain "side effects" and reduce the need for costly synchronization mechanisms.

I guess all these characteristics help extending a case for using Erlang in business critical applications.

One thing Erlang isn't really good at: processing big blocks of data.

Solution 4

We built a betting exchange (aka prediction market) using Erlang. We chose Erlang over some of the more traditional financial languages (C++, Java etc) because of the built-in concurrency. Markets function very similarly to telephony exchanges. Our CTO gave a talk on our use of Erlang at CTO talk.

We also use CouchDB and RabbitMQ as part of our stack.

Solution 5

Erlang comes from Ericsson, and is used within some of their telecoms systems.

Outside telecoms, CouchDb (a document-oriented database) is possibly the best known Erlang application so far.

Why Erlang ? From the overview (worth reading in full):

The document, view, security and replication models, the special purpose query language, the efficient and robust disk layout and the concurrent and reliable nature of the Erlang platform are all carefully integrated for a reliable and efficient system.

View more solutions

Comments

[Eric]

The problem with BAD case studies is that they don't really get famous or see the light of the day.

[Muzaaya Joshua]

WHATSAPP Uses Erlang ! Google it for details

[jldupont]

For some of their telecomms systems.

[Tim]

The paper is an interesting read. It doesn't directly make that generalization about suitability, it indicates that they found Erlang to unsuitable if you are trying to deploy on an IBM Cell BE processor, found in the Playstation 3. It also states they are inexperienced with Erlang. With more experience and suitable hardware they may have arrived at a different conclusion. I get the impression that their code may have included use of non-tail-recursive functions ; if so then it may go some way to explaining their problems with memory, garbage collection, crashes and performance.

[CoderTao]

I think you misread the article. The inability to run on a Cell processor was unfortunate, but it was only a side note. The 12x performance difference between a C++ and an Erlang implementation running on an x86 platform was the real problem, combined with the fact that it didn't scale linearly. That said, they were new to the language, and may have taken a few unwise code paths... such is life. I'm curious about the non-linear scaling though.

[Tim]

I stand corrected on the 12x performance issue with regards to the Intel versus Cell, but I maintain that Erlang can be well suited to CPU challenging scenarios. That's not to say they aren't right : this really might be a problem where a good C++ solution will always beat a good Erlang solution. Perhaps this does go some way towards serving as a reminder to some folks that Erlang, like any other technology, is no silver bullet and it will only shine when used the right way in the right place.

[Kirill Trofimov]

Could you explain the following: "One thing Erlang isn't really good at: processing big blocks of data."

[Christian]

He means things like decoding mpeg data. There is too much numerical computation which Erlang is not optimized for. If the processing just involves shuffling big blocks of data from one place to another, then Erlang is quite good at it. (Files to TPC Sockets, etc)

[jldupont]

You can't update shared blocks of data (there are no pointers in Erlang) and hence data must be shuttled across processes which in turn translate to inefficiencies.

[I GIVE TERRIBLE ADVICE]

CouchDB is not an OO database, it's a document-oriented database.

[Brian Agnew]

@I GIVE TERRIBLE ADVICE - yes, of course. Corrected. I would change your moniker :-)

[JDong]

Just a note, the link to your talk is now private.

[A. Binzxxxxxx]

facebook switched away from erlang: facebook.com/notes/facebook-engineering/… and quora.com/…

[Zack]

To be fair, almost any C++ code rewritten in a modern language would reduce the LOC.

[Jono]

As an aside, Ericsson, I believe, said Erlang achieved 9x9's availability.

[Shelby Moore III]

We’re contemplating improving upon the weakness of Erlang cited here.

[pradyumnad]

Can you update the broken link for the book?