Ask HN: Why isn't Erlang more popular?

It's just not suited for what I do. At work, I do number crunching. Essentially a bunch of simple calculations in a for loop. C++ is excellent for this. I use a lot of Python for rapid prototyping, and as glue code. When I need to do concurrency, it's usually the easiest thing to run multiple instances in parallel, or to submit jobs to a cluster. There is already a well-tested infrastructure in place, and I don't need all the fancy stuff erlang has in this area.

Second, but more important, my colleagues know C++ (good enough at least). If I started to use something else, we couldn't collaborate. We're physicists, not computer scientists or professional programmers.

Then, I often find myself writing GUI code. I wouldn't know how to start writing a GUI in Erlang, but it's trivial in Python or C++.

If anything, I would need a language centered around mutability, so almost the opposite of erlang. A language where everything is mutable, where you can databind to any object. Where you can just make an array of objects and bind it to a graphical widget, and get create, edit, update, delete operations for free. You never have to write `listview.insert(...)`. Maybe the command pattern is part of the language and it is trivial to write an undo function. And finally, it would include multithreading, with only a simple syncronization primitive, the transaction. The goal of concurrency here would not be speed, but GUI responsiveness.

So, I have two very different use cases, for one I can use C++, for the other the ideal language has not been invented (but C# and Python are both not bad). I just don't know what to do with Erlang (and Haskell, Clojure, and all the other hip languages).

Short answer: You have to be slightly smarter than average to use it properly.

Longer answer: The only proper way to learn Erlang is to read the documentation. Then re-read the documentation. All of it. It takes 3-6 months to get proficient, then another 6 months to stop doing things the native or outright bad way.

If you are primarily an "erlang programmer," you can't interview for jobs. Everybody hires for either java, ruby, or python. If you do see a rare "Erlang job" position, they probably actually mean "We want you to understand ejabberd because we based our company around it and it's actually unusable at scale, so you get to fix other people's problems all day long." (Of course, building your own company/services around Erlang stops the "need to interview in other languages" problem.)

But, why can't you interview in Erlang? I guess you can, but the way I work, I have an editor in one window and API docs in the other. Interviewers, sitting up there on their oh-so-high perches, don't like it when candidates want to do quick API lookups for things like parameter order or return values. (Does it take (Fun, List) or (List, Fun)? Does it return Value or {ok, Value} or {value, Value}?)

Short conclusion: Erlang is a system and understanding systems takes effort and practice. People, in general, don't want to learn, they want to do. It's the whole "one year of experience 15 times over" instead of 15 years of growth and advancement problem. It's the "person with 20 years in computing can't write a tail recursive function" problem. It's just a problem.

Alternative question: why don't people understand defmacro (and recursive defmacro) and write their programs from the bottom up?

Bonus analysis: In a world where people just want to learn one thing and use it forever, Erlang doesn't fit. With Python, you can learn it once then keep "extending" it to pretend to get concurrency and other fancy features Python actively rejects at the implementation level. So, you learn Python once, then feel productive because you're duplicating functionality given to you for free in other languages.

Erlang has so much "done right the first time" built into its VM you don't have to reinvent basic parallel computing every time you want to get two webpages at once or serve more than one client at a time from a basic five line server. But—Erlang people know for other tasks, say something better served by numpy, they should jump over to Python or Lua or something else better suited to the task without reimplementing all of the "they did it right the first time" code in Erlang just because they refuse to learn any other language.

I tried it for approximately 6 months (a few years ago). I translated some slow python into fairly idiomatic (IMHO) erlang and got some pretty significant speedups. I had vary little functional programming experience before that, so my comments here come with that caveat.

My hangups:

- lack of easy-to-use string libraries. far and away the biggest pain point. working in bioinformatics, I deal with a lot of poorly-formatted text.

- installing erlang itself was fine, but installing (and finding) any other packages was a PITA.

- documentation could have been better. I can't remember what specifically I disliked but remember being frustrated trying to find info about builtin nuances.

- syntax. this one seems silly from the outside, but the whole commas-here-but-definitely-not-there and other idiosyncracies really made tweaking code and debugging a pain. Go has similar pains around the "unused variable" errors so I know this type of thing isn't particular to erlang.

I have picked up my copy of "Real World Haskell" (Bryan O'Sullivan et.al) about three times; each time ended up nearly starting over and each time making it about ten pages or so more in, (i guess it's a recursive language at several levels). It's a fascinating approach, but egads, it requires a thousand fold more effort to get into than any other language i've learned. somewhere between the monads and the syntax..[hollywood car explosion]

somehow Haskell makes me feel bad about myself; like an ultra strict grade school teacher.

I found Erlang a lot easier to learn than Haskell. I don't really find them to be very similar, especially because they have a completely different evaluation strategy. The syntax and semantics are also quite different. Specifically, Haskell's non-strict (lazy) evaluation turns everything inside out so you tend to write many things in a different way than you would in Erlang.