I'll only take some of these: * Error messages: The current format has two distinct advantages to the experienced programmer: They are Erlang terms and can thu

I'll only take some of these: * Error messages: The current format has two distinct advantages to the experienced programmer: They are Erlang terms and can thus be manipulated easily as such. And they are succinct. I definitely give you that they are not easy to read for the beginner, but for the more experienced programmer, they are actually easy to read. Your critique could be countered by writing a "beginners mode" which transformed the error into a more readable variant. Which isn't that hard to do but it takes resources which are better used elsewhere. * Strings: Most functional languages, be it Haskell, Erlang, Ocaml, Lisp-variants and so on are usually better off with a representation of string-like objects which are symbolic. The reason is that symbolic manipulation is the strength of these languages - exactly as string-manipulation is the distinct advantage of perl. Furthermore the non-academic world in which Erlang was first used, telephony, has very little need for effective string handling, I might add. Not everything needs a string. * Syntax: The syntax makes it harder to move code around, but not very hard. You will find that swapping the order of the last line with something else is a thing you do rarely. Even in pattern matches. At least I don't think it is much of a problem. Yet, I note that refactoring in other languages is not always exempt from similar problems. Changing type in java names in Java requires you to change the constructor call. Moving blocks of code in Python requires you to change their indentation. Hoisting a function out means you must create it. If it really pisses you off you can just write a style where the delimiter is at the beginning of each line and the . is on a line by itself. Then reordering is easy.