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