[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.

[eternalban]

Erlang is a CSP system, first and foremost, and not actors.

[CSP style concurrency on JVM]: https://www.youtube.com/watch?v=37NaHRE0Sqw (Kilim, it should be noted, was benchmarked as scaling better than Erlang/OTP.)

http://lambda-the-ultimate.org/node/4350 (paper in top comment is worth the read.)

Disclaimer: I think Erlang/OTP rocks. But JVM has its moments, as well, and in fairness has earned the "most advanced VM" title.

[jlouis]

Erlang isn't CSP by a long shot. If you take a look at

http://en.wikipedia.org/wiki/Communicating_sequential_proces...

Note that Erlang is different in all three aspects: Processes have identity, messaging is not rendezvous and there are no channels on which messaging occur.

[talentdeficit]

HiPE is the native code compiler, BEAM is the VM.

otp is fantastic, however

[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...

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

[jlouis]

The Erlang VM tends to shine when it is given situations with an enormous amount of load and a high level of concurrency. None of the "ShootOut" problems really reflect where the time is spent optimizing the Erlang VM, so it is not that much of a mirror.

The BEAM interpreter is an interpreter though. And while it is rather fast, it is still just an interpreter and for purely CPU-bound problems, you have many languages, most compiled, that will beat it soundly.

[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.

[luriel]

Here are some slightly more detailed benchmark results of Go vs. HiPE: http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

Note: Go development is done mostly on 64bit, and the 32bit port is a bit of a second class citizen specially regarding performance.

[ConstantineXVI]

Is there anything specific that makes BEAM special compared to JVM? Would a "Clobure" or "BRuby" see any upshot vs. their JVM counterparts (barring library support)?

[hungryblank]

BEAM has this very interesting concept of scheduling, working from a very high level point of view as follow

1) there are a number of processes wanting to be executed

2) schedulers (generally one per core but is a configuration option) schedule on process and run it for a fair amount of operations. This makes systems with heavy parallelism run very smoothly since single processes won't hog cores but will only get a fair amount of scheduling.

On top of that the fact that the BEAM is directly aware of processes (actors) makes the system very transparent (you can look in depth into a single process and examine it's heap size, scheduling consumption google for erlang process_info to get an idea)

Very interesting with this regard are the slides about the erlang VM by Robert Virding http://goo.gl/PHfeh and from erlang "half word" VM talk by Patrik Nyblom http://goo.gl/2LD9S

[fullmoon]

There is http://elixir-lang.org