Edit: even Haskell seems to be about 7x faster than Erlang (according to ). Suddenly, Haskell looks like a good candidate for writing a distributed server :) Can somebody comment on this?
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.
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.
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?
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.
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.
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.
It's a fine tool for this, too.
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).
It's a fun product :)
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.
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 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.
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)
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.
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.
His erlexec thing is quite useful: https://github.com/saleyn/erlexec - I started contributing to it myself before I realized who he was.
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.
But whatsapp is not a latency-critical application.
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.
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...
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)
"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."
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. There are few large scale systems in Erlang, including one Amazon AWS service, 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 or if you not tied to Erlang chose a language that is focusing on that more.
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.
If you'd looked at that web page you'd know the answer to "hipe enabled?"
Same as you'd likely do with Ruby or PHP or whatever.
Are you saying that such projects are better written in a combination of Erlang and C/C++?
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.
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."
Facebook has the money to throw at something like that with no problems. Not everyone does.
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.
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...
C++ lets you write fast code.
Haskell is interesting.
If you want maintainable AND fast, have a look at Rust.