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.
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.
[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.
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.
otp is fantastic, however
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.
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.
I hate this kind of mentality. If you can't look at things honestly, you'll never improve your favorite language(s).
Note: Go development is done mostly on 64bit, and the 32bit port is a bit of a second class citizen specially regarding performance.
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
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.
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.
Has anyone who's used erlang tried playing with Haskell in the same role?
* Erlang: fault tolerance, distributed systems, absolute performance less important. * Haskell: correctness important, multicore+shared memory performance a main focus, distributed systems less of a focus (cloud haskell)
I wouldn't write my webserver in Erlang, for example, but my distributed object store, that's another story.
http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlan...
1. server loads the data from S3 on start (sessions are sticky to a particular server)
2. user data gets mutated on that server for the lifetime of the session
3. the data gets written back to S3 on session end
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?
(1) In C++ you may get hard crashes, so to get reliability you need to use high-overhead OS processes. Erlang allows you to hundreds of thousands (yes, really) of processes because they are really lightweight (76 words + heap/stack). Also, copying within the same address space has much lower overhead (no system call/context switch) and serialisation is much simpler.
(2) Because of immutable data you can do have nice fault tolerance as follows. Imagine you have a request handler function that takes a state and a request. However, the request is malformed or triggers a bug in the handler. In a language that doesn't enforce immutability you have to restart the handler process because the state may be in an inconsistent form. In Erlang you would just discard the request (or send an error message) and handle the next request with the unmodified state.
(3) Pattern matching makes receiving a message very convenient.
I probably forgot a few things, but this gives you an idea.
It might be possible to achieve that isolation if you stick to strict coding practices, but the point where it's going to fail is when you import another library, written by someone else.
Because C++, Java and many other languages (including F#, Scala and others which have message passing libraries) do not have the enforced isolation of state, nor the ability to add notation to indicate that some piece of code is free of side effects (including all of it's dependencies), you're always going to have the risk of breakage when importing a library. The only way you can be sure that a library is actor-safe is to read it's source code - and if the source code is not available, then you're out of luck.
Java and C++ could have the potential to do actors correctly by adding the notation for side-effect-free code, using custom annotations/attributes on all functions which are actor-safe, and using some compiler extension or static analysis tools to prove correctness. I'm not aware of anything that does this for the mentioned languages though.
On the other hand, if you implement message passing in any purely functional programming language, your actors are automatically safe for free.
Not sure why this is so tough for people to understand. You usually don't need a whole new language to use a paradigm.
edit: </internet sarcasm> ducks
I don't believe it is possible to do real concurrency on the JVM, without rewriting key parts of the JVM.
Because rewriting or shimming the 10MM lines of code in the libraries one depends on outweighs this one particular benefit of erlang.
> I don't believe it is possible to do real concurrency on the JVM, without rewriting key parts of the JVM
Define "real concurrency".
Erlang's actually all about reliability. It's the secret decoder ring to its design, not the actor model or message passing, which serve as the ways it gets to reliability. (Even to some extent its syntax. Excepting comma-period-semicolon which is just dumb.) And one of the principles of Erlang is that you don't have reliability when you are running on only one set of computer hardware.
If you need to execute an expensive computation or make a blocking call inside an lthread, you can surround the block of code with lthread_compute_begin() and lthread_compute_end(), which moves the lthread into an lthread_compute_scheduler that runs in its own pthread to avoid blocking other lthreads. lthread_compute_schedulers are created when needed and they die after 60 seconds of inactivity. lthread_compute_begin() tries to pick an already created and free lthread_compute_scheduler before it creates a new one.
It just does the blocking call on its own pthread. That simply does not scale the way Erlang does.
One day there is hopefully an OS where each file, socket, device, etc. is an actor with a message queue. Then you can really be concurrent :-). Even Erlang can then be more concurrent...
I do agree that actor models implemented at the OS level is much cleaner, but when it comes to CPU hogging sections, messages queues are not the answer.
Stop that, right now. You're supposed to be hackers. New technology isn't supposed to scare you this much.
Erlang doesn't use the C style syntax. BIG WHOOP. Yeah, it looks "weird" at first but don't be scared off by it.
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.
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.
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.
I promise you that you'll really enjoy the much smoother ride.
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.
But be serious about it. Do a chapter each night from the armstrong book.
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.
Seriously. Stop rationalizing.
An obvious case you've omitted, is that people already have existing codebases written in other languages, and rewriting them all in erlang is not an option. Attaching an actor library to "X" language can give us many of the features offered by erlang with our existing codebase, and allow us to continue using our existing skills and paradigms.
Erlang does an excellent job at solving certain issues, but it's lacking in many other areas that "X" might do a better job of. If my project needs both the fault tolerance and concurrency of erlang, and feature "A" which language "X" is good at, but erlang not so good at, then choosing erlang all the time might not be the right solution.
I'm personally a fan of polyglot programming. We should pick the most suitable languages for each task, then we wouldn't need to keep re-inventing programming languages and libraries to emulate other languages. It's quite an idealistic view, but there's certainly ways we can improve the interoperability between languages, including erlang's - which is quite limited so far.
An example of such approach is the (now discontinued) Axum project from Microsoft Research. It offered many of the ideas of Erlang, but built onto the .NET framework and largely compatible with existing code. Axum could call, and could even contain almost any C# code inside it, although it was a restricted version of C# which had isolated states, and no static variables - something that high standard codebases omit anyway, regardless of the whether language allows it, because it's been known good practice for a long time that shared state causes problems.
The Actor Model existed long before Erlang, and will feature in many other languages other than it - whether or not they are successful is a different matter, but programming language designers would be wise to have a good knowledge of Erlang, and many other languages, so they're not re-inventing the wheel badly. Concurrency and fault tolerance should be considered from the start.
I personally think we can do better than Erlang - or at least offer the same without sacrificing every other paradigm to achieve the aims of erlang. (And Haskell will probably be the language to better it).
Erlang really is the simplest of any serious language I know, after a little of erlang you will be pining for it when debugging some accidental misuse of globals in javascript.
Saying that no other environments will be able to provide the same isolation and elegant message passing is wrong, erlangs vm is good but it is not magical, but for now it does it best.
I'd expect an equivalent toolset on a different platform to have an equivalent learning curve if it existed at all.
http://blog.plataformatec.com.br/2011/03/why-rubyists-should...
Here's something I wrote about it 5 years ago:
IF you spend about 2 weeks working on erlang, it becomes really easy to use.
The learning curve is not nearly as steep as it appears-- its just that the syntax initially looks so alien that its quite scary.
I know the feeling, I went thru it, but it is well worth it.
