[dvt]

Same old hype. Erlang is good I guess, and I've used it in production a couple of times. But it's just a language that solves 3 problems but creates another 30. Just like C++11, Dart, Go, etc.

This kind of belligerent rhetoric (we're solving the right problems, everyone else is dumb) is the kind of drivel that gives momentum to language zealots that think language X is better than language Y.

I've contributed to Google Go in the early phases and I was naïve and really believed that Go was the "next big thing." But it turned out to be yet another general-purpose language with some things that were really interesting (goroutines, garbage collection, etc.) but some things that were just same-old same-old. Now, I'm editing a book about Dart and I've since lost my enthusiasm for new languages; I can already see that Dart solves some problems but often creates new ones.

And in a lot of ways Erlang sucks, too. The syntax is outdated and stupid (Prolog lol), it has weird type coercion, memory management isn't handled that well (and many more). Of course, since Facebook uses it, people think it's a magic bullet (Erlang is to Facebook like Python is to Google).

The article also forces readers to attack a straw man. Often times, algorithms simply cannot be parallelized. The Fibonacci sequence is a popular example (unless you use something called a prefix sum -- but that's a special case). So in many ways, the rhetorical question posed by the article -- "but will your servers with 24 cores be 24 times faster?" -- is just silly.

[davidw]

> This kind of belligerent rhetoric

For some context:

http://joearms.github.com/2013/03/27/promoting-erlang.html

He's new at "rah rah!" promotion of his language, so cut him a bit of slack.

[rdtsc]

> The syntax is outdated and stupid (Prolog lol),

How is it any more or less stupid than curly bracket.

Show me another production ready language that has the same level of pattern matching as Erlang.

> Often times, algorithms simply cannot be parallelized.

Who cares. How many people here have implemented individual algorithms and delivered them as units of execution. Sure middleware companies maybe sell a cool implementation of A* or some patented sort algorithm.

You can think of parallelization at system level. Can you handle client connections concurrently (and in parallel?). If yes, that covers a large chunk of the usage domain for platforms these days.

> memory management isn't handled that well (and many more).

Can you expand on that?

[davidw]

> How is it any more or less stupid than curly bracket.

When you move a few lines around to refactor, you have to pay a lot of attention to the "ant turd token" line endings. I like Erlang, but still find this aspect of it annoying.

[Peaker]

Haskell has nicer pattern matching capabilities.

[peerst]

No it hasn't :-) Just to stay on your level of detail

[banachtarski]

> memory management isn't handled that well.

So... how would you have handled it, out of curiosity.

[dvt]

> So... how would you have handled it, out of curiosity.

Imo separate heaps is the first big mistake. Even implementations like Erjang (Erlang on the JVM using the Kilim microthreading library -- which I've also contributed to) improve on the copy-from-heap mechanism prevalent in vanilla Erlang. Not only that, but Erlang's memory allocator isn't that well-suited for multi-threaded allocations, which also means that Erlang doesn't (can't?) take advantage of tcmalloc, umem, hoard, etc.

[wrboyce]

Maybe I am missing something, but aren't separate heaps (i.e., no shared memory between processes) one of the things that makes concurrency such a "joy" in Erlang?

Why do you feel the major selling point was the first big mistake?

[EvanMiller]

Well, technically there is a difference between separate heaps and no shared memory. Data in Erlang is immutable, so processes could use a combined heap, but they still wouldn't have read-write shared memory.

However, in my opinion separate heaps was absolutely 100% the correct design decision. The main benefit is not having to worry about the effects of a long-running, stop-the-world garbage collection, which can have catastrophic effects on user interaction, server response times, request queue lengths, etc. An additional benefit is that the language implementers can use "dumb" algorithms for garbage collection and avoid a large class of difficult-to-track bugs.

Robert Virding talked about these issues at some length at this year's Erlang Factory; hopefully the video will be posted soon.