Why Erlang?

A lot of intros to Erlang miss an important point: Erlang is about <i>fault tolerance</i>, 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.<p>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.

I think this is a great article but misses some of what I think are the most essential points of what makes Erlang great.<p>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.<p>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).<p>Here's what stands out about Erlang to me, in contract to comparable options.<p>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.<p>Secondly, and perhaps more importantly, OTP.<p>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.<p>The systems responsible for controlling emergency services, global telecom infrastructure, many large MMOs, and countless other applications <i>are</i> Erlang. If you trust 911, you can trust Erlang.<p>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.

Can anyone comment on writing erlang style apps in Haskell?<p>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.<p>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.<p>Has anyone who's used erlang tried playing with Haskell in the same role?<p>[1] <a href="https://github.com/jepst/CloudHaskell" rel="nofollow">https://github.com/jepst/CloudHaskell</a>

What I gather from the slides:<p>1. server loads the data from S3 on start (sessions are sticky to a particular server)<p>2. user data gets mutated on that server for the lifetime of the session<p>3. the data gets written back to S3 on session end<p>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?

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.

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

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

In lthread, a coroutine lib, (<a href="http://github.com/halayli/lthread" rel="nofollow">http://github.com/halayli/lthread</a>) 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.

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.<p>Stop that, right now. You're supposed to be hackers. New technology isn't supposed to scare you this much.<p>Erlang doesn't use the C style syntax. BIG WHOOP. Yeah, it looks "weird" at first but don't be scared off by it.<p>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.<p>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.<p>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.<p>I promise you that you'll really enjoy the much smoother ride.<p>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.<p>But be serious about it. Do a chapter each night from the armstrong book.<p>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.<p>Seriously. Stop rationalizing.

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.