Hacker News new | past | comments | ask | show | jobs | submit login

Erlang looks interesting. However, the only problem I have with starting in Erlang is that on the great computer language shootout, it shows that Erlang is about 10x slower than C++ on most examples. And about 3x slower than Go [1] I know that the problems on this website are not specifically "concurrent" problems, but still, even a distributed web-server must do some non-concurrent stuff at times :) Are my concerns correct/justified?

[1] http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...

Edit: even Haskell seems to be about 7x faster than Erlang (according to [1]). Suddenly, Haskell looks like a good candidate for writing a distributed server :) Can somebody comment on this?

Which do you need sooner; fast? or correct and scalable?

Erlang is built first for fault tolerance, not speed. The decisions that went into that make it also really, really good for concurrency and distribution (and so that's what it often gets touted for).

The decisions that went into C++ were for speed, and compatibility with C (and all that entails).

If you've got something truly resource intensive, yeah, you're going to need a lower level language. That's largely unavoidable. Erlang.org flat out states don't use it for number crunching.

I'd guess that 90% of what is programmed in the wild isn't that resource intensive. And given that, I'd go so far to say that most of what I've coded in Erlang is more performant than what I've coded in Java (haven't done enough C/C++ professionally to have useful data points). Why? Because the abstractions and conventions lead me to writing better code; the tooling lets me profile and find bottlenecks more easily, and even code I tweak for performance is oftentimes cleaner than it started, rather than more arcane.

Joe Armstrong, the founder of Erlang, is quoted in OTP in Action as (paraphrasing as I don't have it on hand) - "First, make it correct. Then, make it beautiful. Then, if you need to, make it performant. Chances are once you've made it beautiful you'll find it sufficiently performant". And that's been my experience with Erlang.

I feel like Rust in a way is trying to be somewhere between Erlang and C++, and in a way thats what gets me so excited about it.

Yeah I like Rust as well. Probably for the same reason you mentioned. Lately (last year or two), I think they have been moving to be closer to C++ than to Erlang.

Nothing wrong with it just an observation. Say they shed their runtime system. libgreen got moved to a separate package. Instead of relying and encouraging creating mutliple tasks and have them fail!( well panic!) now they are moving to have error traits as return values.

Again nothing wrong with it. I think it is a good move. Just observing how it started off at one side and moved towards the other.

I think it calls for a Rust-Erlang interop.library just like there is a Java one. I would like to be able to have a Rust node. Or say create NIFs in Rust perhaps.

> Which do you need sooner; fast? or correct and scalable?

Well, if I need all of these options, then Erlang is obviously not the way to go. In that case, Erlang might work as a prototyping language.

My impression is, from what I've read here, that Erlang might be the preferred tool for situations in which latency is not of paramount importance. For example, when sending text-messages over the internet, it doesn't hurt if the message takes 1 or 2 seconds longer to reach its destination. However, for a webserver, every second it takes longer to load a webpage means that you lose customers.

Do you think that's a fair characterization?

If you're just delivering content, not number crunching, I doubt your bottlenecks are CPU, and you shouldn't see Erlang take 10x as long. In fact, you'll probably deliver a better experience in Erlang, because of its approach to concurrency; your average latency will likely be a bit higher, but your extremes will likely be lower.

In fact, since you started with benchmarks, let's return to benchmarks (I find them to generally be useless, but you're looking at them, so why not) - http://www.techempower.com/benchmarks/

Compare CPPSP (the fastest! C++!) with cowboy (a popular web framework in Erlang). They're being run on the same hardware (so we're not talking about ability to scale across nodes even), serializing JSON.

Cowboy is about 1/4th the throughput (requests per second). Now let's look at latency. Cowboy took about 4 times the time, .8 ms on average per request to the CPPSP's .2. Great, C++ all the way, right? Err...no. Look at the max and standard deviations.

Cowboy had a max latency of 3.7 ms. CPPSP had a max of 134.6. Standard deviation of cowboy was .3 ms. Standard deviation of CPPSP was .5 ms.

So Cowboy is still really quite fast, more predictable, and has far smaller outliers. What are people going to be more likely to object to, waiting 3.7 ms, or 134 ms?

Couple that with the reliability Erlang provides, the ability to scale straight outta the box (so if you find you're hitting a throughput issue you have a clear path forward), and the joy of functional coding...and it's pretty compelling, to me at least.

> Look at the max and standard deviations.

This, times a million. 99th percentiles and standard deviation are what truly matters in benchmarks. To liken benchmarks to automobiles, requests/second is horse power and 99th percentile/standard deviation are torque.

Fair enough. This makes sense.

"In that case, Erlang might work as a prototyping language."

If you can write reasonably idiomatic Erlang from the get-go (design things in terms of gen_servers and such, instead of single-process monoliths), Erlang is a great prototyping language, because anywhere you send a message and receive something back is a point where you can drop in some other implementation of that particular bit without affecting the system as a whole.

You'll find in practice that the only time you'll be tempted to do that is if something is computationally expensive. Erlang is pretty darned good at reading from and writing to sockets in general.

I've personally used Erlang in Real Time Bidding scenarios, where soft-real time constraints exist and is on the order of milliseconds.

It's a fine tool for this, too.

Erlang's strength is in its virtual machine which has supervision trees built-in, a built-in DNS system, built-in inter-node RPC, hot code reloading, massive concurrency, etc...

I still haven't experienced a programming environment that replicates the Erlang/OTP environment. Period.

Haskell is amazing, I've built my company on it, but we're also building our company on Erlang - Haskell's tooling around distributed computing is much more immature than Erlang's (although Haskell's concurrency primitives and STM libraries are extremely mature and arguably better than Erlang's actor model).

out of curiosity, what's your company and/or field?


It's a fun product :)

When you say Erlang is slower than C++, You are right. It is also slower than Go.

Ruby is also slower than C++ & Go, But Ruby on Rails is not only popular but a very productive web framework which can help you build your app with a productivity that C++ or Go can't match.

When you write a high quality, fault tolerate system, the raw speed comes at the end. Erlang shines when you write a concurrent system plus its design is very unique. Erlang I would say isn't only a language but a whole philosophy of Software development. Once learned you can apply to many other platforms.

All in its a joy to work with functional languages and Erlang is perhaps the most commercially successful functional language.

The added fault tolerance of Erlang is not free - it adds complexity and overhead. Would you rather maintain an distributed Erlang system running 100s of tasks on 10s of machines, or a simpler C++ based system that due to performance can run on a single machine? Erlang may scale out, but does it scale down?

This is similar to the ADA argument -- it's great and can be used to write safe software, but do you need safe software a month from now or unsafe a week from now? Global networks with millions of users are extreme outliers.

A few points:

- A large system never runs on a single machine if you want any level of realistic fault tolerance. Two nodes is a bare minimum, 3 an acceptable one.

- The number of nodes will always depend on where your bottlenecks lie. Erlang developers would be rare and few to write CPU-bottlenecked code directly in Erlang. The usual approach would be to write your system in whatever is appropriate, and then too coordinate things with an Erlang layer.

- I would a hundred times more willingly maintain and debug a running Erlang system than a C++ one. I'm kind of sold on the idea though, and wrote http://erlang-in-anger.com to share my experience there.

> and Erlang is perhaps the most commercially successful functional language.

Out of interest, what makes you say that?

Looking at the TIOBE rankings (not that this is definitive), Erlang doesn't even make the top 20 languages, when F# and R do:


Is there a reason you think it's more successful in the commercial world?

(btw, I'm a fan of Erlang - unfortunately I don't get to use it on a regular basis; other than products built on it: RabbitMQ mainly)

Erlang is developed by the Ericsson as a product to use for themselves. Its not a research language like Haskell but developed for a niche and when I said commercial I meant that it is designed as a commercial product. I have seen more Erlang systems than any other functional language.

Just to mention one, RiakDB, a successful distributed software system is developed on top of Erlang. Actually I've yet to see any other product used by 100s or perhaps 1000s of developers developed on F# or Haskell. Not to mention, almost over 80% of telecom industry is running on Erlang.

Erlang is used in infrastructure projects. A few I know of:

Rabbitmq -- probably the most popular messaging system

Riak -- distributed, fault tolerant database

WhatsApp -- managed to route billions of messages a day with only a handful of engineers and servers.

Ericsson -- pretty much got the market for cell base nodes cornered. Chances are about 50% if you use internet on your smartphone, that Erlang will be involved.

Some firms on Wall Street use Erlang -- remember Serge Aleynikov case, he is an Erlang programmer.

Ejabberd -- a very popular XMPP server

CouchDB/Cloudant(IBM) -- another database and database-as-a-service company use Erlang.

So I would still say the original statement holds. By success might mean the amount of work being done not amount of people writing code. Think about WhatsApp. It was only 10-20 engineers that worked on the back-end yet think about the massive amounts of data they were able to handle.

> Some firms on Wall Street use Erlang -- remember Serge Aleynikov case, he is an Erlang programmer.

His erlexec thing is quite useful: https://github.com/saleyn/erlexec - I started contributing to it myself before I realized who he was.

Also the Heroku routing layer.

Probably because it is used in Ericson switches etc? A lot of stuff has been sold on the back of Erlang even though it is probably a niche language in terms of users/popularity.

TIOBE not only isn't definitive, but there's little reason to think that its that much more meaningful than throwing darts at a board for its declared meaning ("an indicator of the popularity of programming languages") or the things it claims to be useful for ("to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system").

I disagree with your final conclusion. You also aren't considering the number of unspoken (big, as in banks, or the DoD) users of, say, Haskell because for many it's a competitive edge.


1) There are trade offs, sometimes you trade development time for execution time.

2) Erlang is "fast"/scales, ask whatsapp

3) A lot of people worry about execution but have enough spare CPU cycles to compute the universe.

4) Benchmarks mean nothing, you must figure out what is meaningful to you. You won't compare a ferrari and a minivan? Well, you could, but yet, find that a minivan is more practical for your daily needs.

> 2) Erlang is "fast"/scales, ask whatsapp

But whatsapp is not a latency-critical application.

If you're controlling car brakes, no, don't use Erlang. That's called "hard real time" and mostly gets written in C or Ada or those kinds of low level things: http://en.wikipedia.org/wiki/Real-time_computing

For most other things, Erlang is a fine choice. In your other comments you talking about web pages. People compose those all the time with languages like PHP and Ruby, and things mostly work out.

Odds are, with a lot of web stuff, a decent portion of your latency is going to be in the data layer anyway.

By latency, what do you mean? Erlang excels with Input/Output (the VM's I/O manager is well-tuned) and network applications.

I think WhatsApp is latency critical, no user ever said it's okay to have their message show up minutes after it was sent if both parties were on a good internet connection...

I don't think your concerns are justified: the added-value of Erlang is not its speed but its reliability and its tooling to build large, stable softwares.

Try to look for something that works at scales you're interested in, break it down to its components and rearrange them into a simple architecture, then only can you consider performance. It turns out the lack of performance you feared at the beginning doesn't actually happen; in the meantime you'll have built a robust software (and, if you want to start the language, you'll have learnt a whole new way to program)

Also shown on the benchmarks game website --

"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."


I think you raised valid concerns about the single node performance of Erlang. If you have a single node problem or you are looking for raw speed Erlang is not the best option.

The fun fact is that most distributed systems don't really care about 7x slower too much. Those care about scalability, reliability and fault tolerance more. One of the most reliable software systems out there was written in Erlang and as far as I know, there are few system can match that sort of uptime[1]. There are few large scale systems in Erlang, including one Amazon AWS service[2], and bunch of others like WatsApp.

I also like to mention the VM that is pretty amazing. There is per process (not an OS process) garbage collection that enables Erlang to meet with super tight SLAs in terms of latency. Ideal for high scale websites, doing the routing, but also for moving data from A to B. The concurrency model is also one of the strongest features of Erlang. Message passing is very powerful and enables you writing asynchronous code that is still easy to read and follow. Go can match that probably with channels and go routines though.

If you care about single node performance you can either use NIFs[3] or if you not tied to Erlang chose a language that is focusing on that more.

1. http://ll2.ai.mit.edu/talks/armstrong.pdf 2. http://web.archive.org/web/20110623221347/http://www.satine.... 3. http://www.erlang.org/doc/tutorial/nif.html

Erlang is about 10x slower than C++ on most examples.

damned lies and benchmarks. hipe enabled? VM tuned properly? attempt to use halfword emulator? comparing C++ the compiler optimized down to SSE2 instructions to an emulator VM loop?

How much slower is Ruby than C++? Ruby runs every startup in the world. This website is the home of "DO THINGS THAT DON'T SCALE" including using fast to write programming languages at all costs even if 3 months later their "we have modules for every occasion!" design will be inadequate (you are testing your _ideas_ after all, not programming language speed, at least of the majority of use cases for people on this site).

a good candidate for writing a distributed server

distributed means you need monitoring. monitoring means you need supervision. supervision means you need restart strategies or failover or other promotion mechanisms. all that is built into erlang for free. optimize for _reliability_ not for speed when creating distributed systems.

Damned innuendo.

If you'd looked at that web page you'd know the answer to "hipe enabled?"

It's silly to compare Go to Erlang, which is decades older and more mature. Erlang has built-in clusters, a robust actor framework and a powerful pre-emptive VM. It's optimized for High Availability/Low Latency applications, not "raw" speed or throughput.

You wouldn't use Erlang for number crunching: you'd write some C code and communicate with that.

Same as you'd likely do with Ruby or PHP or whatever.

Okay. But let's take the example of the C++ webserver framework written by Facebook employees, which was discussed here a few days ago, [1]. This project contains lots of protocol-handling logic for HTTP/1.1 and SPDY, and beneath that TLS.

Are you saying that such projects are better written in a combination of Erlang and C/C++?

[1] https://news.ycombinator.com/item?id=8563199

Facebook has two scaling problems. One is the code, sure, but one is also the employees. They need to be able to hire and scale out their teams, and have had to do so quite quickly.

It's easier to find C++ people than it is Erlang. That is a consideration.

It's why Facebook chat was originally in Erlang, then switched to PHP. Facebook already had a lot of PHP devs, they are a lot easier to find, so rather than having to bring people up to speed, or keep a dedicated team always slightly free to be able to handle issues for chat, they rewrote it in PHP.

There is no magic bullet, not even Erlang. You have to weigh a variety of considerations, and pick appropriately based on them. But dismissing Erlang because a benchmark showed it to be slower is likely a mistake; dismissing it because you can't hire fast enough for it is a reasonable business decision.

>It's why Facebook chat was originally in Erlang, then switched to PHP. Facebook already had a lot of PHP devs...

You sure about that? I was curious and googled and from the Quora reply below it seems they switched more from Erlang to their own C++ libraries because:

"...some of the abstractions Erlang had that allowed one to transparently have a distributed system across multiple machines actually caused reliability problems -- one server in the group would fail and cause cascading issues. Secondly, we found a number of instances where Erlang wasn't scaling well to multiple cores."


It's a matter of economics. If you have the resources to throw at a problem and write it in C++, it'll probably be faster, in the end. However, it might also take longer and be less flexible. And with networked stuff, you want to be really careful, too.

Facebook has the money to throw at something like that with no problems. Not everyone does.

>Edit: even Haskell seems to be about 7x faster than Erlang (according to [1]). Suddenly, Haskell looks like a good candidate for writing a distributed server :) Can somebody comment on this?

One of the best kept secrets of Haskell, it can be very fast, supports multiple concurrency/parallelism options. The Yesod team does interesting performance work on the Warp server:


That said, Erlang is really fast at things it was designed for. Try downloading Zotonic or some other Erlang app, get it running, and compare to others like Rails. Sharp, responsive, fast.

This is correct. I tried Erlang with ProjectEuler and creating prime number via sieves with Erlang takes forever compare to C++.

Erlang is not something you want to do for numerical crunching.

Erlang is for a very specific set of problems and it's concurrency.

For any numerical stuff you can off load it to other languages...

Erlang lets you write maintainable, robust code.

C++ lets you write fast code.

Haskell is interesting.

If you want maintainable AND fast, have a look at Rust.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact