Having used Erlang, Ruby, and Java in production, I can say all these langs offer the ability to do just about anything. Its a matter of style with each lang having strengths and weaknesses. Also a matter of library choice so you don't have to roll your own for everything. Erlang a few years ago had many libraries missing for mainstream web app needs. Although Java and ruby have multiple options in almost every category, erlang seems to have "enough" options these days.

I don't agree that erlang fails the "don't repeat yourself" test. In fact, I think ruby fails this test miserably in that you have to write so much test coverage. Although Ericsson devs wouldn't agree with this, I found that my code was my tests. I think the difference of opinion has to do with how the apps are used. My apps were end user web apps and my code was solid enough to be its own tests. Ericsson's code is enterprise grade telecom switches and their business model demands test coverage far beyond what most web apps demand. If you tried to write telecom switching code in ruby, your tests line count would be multiples, perhaps an order or magnitude, greater than the line count of the Ericsson erlang tests.

Ruby is class based OO programming, erlang is functional oriented. My erlang webapp line count was very reasonable. I'm not sure I would have fewer lines of ruby for the same app. The syntax sugar that makes ruby so appealing is a drawback as well at times: the code can be ambiguous with the only way to be certain of what it does being to write tests. Erlang syntax takes getting used to, it certainly doesn't have the immediate appeal as ruby. But it makes up for this in that once you are comfortable reading erlang, you can simply read the code and be certain of what it does and that it does it correctly.

What I mean by repeating yourself is code like this:

    skip_past_separator([]) ->    
	[];
    skip_past_separator([$; | Rest]) ->
	Rest;
    skip_past_separator([$, | Rest]) ->
	Rest;
    skip_past_separator([_ | Rest]) ->
	skip_past_separator(Rest).

(From mochiweb). That sort of thing appears to pop up with some frequency in Erlang code, and it seems wasteful.

It's not wasteful, it is just putting the "logic" into the pattern matching at the function selection level. In Erlang you can usually take the first level of case/if statements or arg parsing and put them into the function definition. You do end up repeating certain patterns when defining the function head, but it lets you get away with a lot less repetition in the body of the function.

Different strokes I guess, but in my experience I found myself repeating code a lot less in Erlang due to the functional nature of the language and because it made certain bits of repetition in the code more obvious due to the "shape" of code in my editor.

I'm guessing your example is a matter of factoring and how/if the frameworks/libs suite your needs. Rails provides DLSs which have just the right interface to allow you to not repeat yourself in many use cases. If your erlang libraries do not, thats a function of the lib/frameworks, not the language.

In terms of "suiting my needs", that's an example from mochiweb itself, so my needs have nothing to do with it.

In terms of refactoring... I've seen code like that scattered through Erlang often enough to have a slight dislike for it (it is not a Major Problem with the language, and pattern matching is elegant).

And to some degree - it is a function of the language:

     foobar(a, b, c=1) ...

is a lot less code than

     foobar(A, B) -> ...;
     foobar(A, B, C) -> ....

So I will stand by my statement that Ruby is generally more succinct than Erlang, which is something that strongly pushes me towards using Ruby for most things, and Erlang only where it really shines.

I don't dislike Erlang - quite the contrary - I first encountered it professionally in 2003 and have dabbled now and then with it. I just think it can be a bit "uneven" - which makes me think it will likely never catch on as a very widespread general language.

And I don't believe in "the right tool for the job" - most people are going to know a few languages (at best) and stick with them, because for most things, it's cheaper in terms of overall effort to do something with a language you know than doing it with something you don't and have to learn (also likely not doing as good a job, because you're new to it), even if the result isn't perfect. So languages that are niche only, in my mind, are probably going to be less popular than they could have been if they were more general purpose.

If you're not matching on variable numbers of arguments, you can just have 1 function sig and a case statement.

The thing I dislike most about erlang, besides the lack of a good macro system, is that the repl is full of annoying special cases, so you have to actually stick your code in a file with a proper module name and compile it in order to test stuff :(

Pattern matching with functions is more 'idiomatic' Erlang, though, than case statements. At least that's what I've seen.

Perhaps a call to dropwhile could be used instead:

http://www.erlang.org/doc/man/lists.html