1. Error messages are sometimes cryptic and that is indeed a language flaw. Line numbers would be absolutely fantastic to have and it's a shame they're not ther

1. Error messages are sometimes cryptic and that is indeed a language flaw. Line numbers would be absolutely fantastic to have and it's a shame they're not there. I can agree on that. Other languages, however, do not uniformly do a better job at being clear when crashing. It's not a unique trait of Erlang to have unfriendly error messages. 2. Strings are important, but not the list type of strings all the time. Erlang, as I mention in the article, has 3 types of strings, and atoms. Jlouis' article had the best arguments for the strings not being that necessary (or rather, too depended upon in general circumstances). See PHP for an example of a language that depends on strings too much for everything. This is also really dependent on the type of application you work with. Telecom software barely needed strings and rather needed ways to handle binary protocols. Some web apps will need them more than others. I might have painted them all with a brush too wide -- working with Erlang brings me to issues where strings are not needed that often and are frequently used as an opaque data type that you just pass on to some other piece of code somewhere else. 3. Yes, you need to create and maintain the chain of supervisors yourself. I am not aware of any AI system good enough to figure out what is alright to have crashing and what isn't, or how to react when problems arise, when to give up on restarting processes, etc. I have my doubts about 'nothing stops you from having them in other languages'. I know Scheme with Thermite had them. What other languages have supervisors, monitors and links that can even work across nodes? 4. Refactoring is a valid point, and there are very interesting tools for that (see Wrangler: http://www.cs.kent.ac.uk/projects/wrangler/Home.html http://www.cs.kent.ac.uk/projects/wrangler/Home.html), but there is more to refactoring than moving bits of code around: handling dependencies, breaking existing functionalities and regressions, etc. Syntax only makes one of all the problems of refactoring difficult. Referential transparency, success typings and all the other tools make it a lot easier. It's not all or nothing here. 5. It's fine that they might never will. Erlang isn't for everyone. I found it maps to my mental model of organizing things very well -- much better than any OO language out there. I can readily accept that for many people, the opposite is true. 6. Erlang is anything but academic at its roots. It was created in industrial setups by computer scientists and engineers with real problems to solve. It's been battle tested for decades and has received academic interest only afterwards and is now enjoying a presence both in the industry and in academia.