Ask HN: Why isn't Erlang more popular?

All your thoughts most gratefully received - the internal debate is pointless and fruitless.

Pierre Fenoll has provided a link to an extensive list of links (and summarised them) about why it has not taken off: https://github.com/fenollp/kju/blob/master/criticisms.md

So, it's probably not any sort of technological issue--I'm pretty impressed by the tech behind Erlang.

It's the language (somewhat Prolog-ish) that is weird and uncomfortable to people new to it. Elixir helps with this, but still, every time I've tried to pick up Erlang I've rapidly been turned off.

It's the community--rather, the lack of one. Right now the product I'm working on pretty much plays directly to the strongpoints of Erlang: high-availability, high-scalability, soft-realtime performance, and straightforward error handling. Should be an obvious play.

But, I can't find Erlang developers where I live--which is funny, because at least one company with a good exit in town is an Erlang shop.

Maybe we'd be better off trying to open a branch somewhere in Europe to poach ex Ericcson folks. :(

EDIT:

More thoughts.

Prototyping is just a hell of a lot faster in JS/Ruby than in Erlang, though this could be a side-effect of it being a lower-level language more suited to infrastructure stuff. Then again, I've seen at least one 3D modeling package written in it ( Wings3D ).

Maybe that's part of the problem: just what the hell is Erlang good for? I see it used for really hardcore systems stuff, but it also seems to want to serve web pages, and draw 3D objects, and orchestrate builds, and all these other things. It doesn't seem to have a clean focus in the public eye right now.

Something not mentioned in the the list of criticisms linked by gordonguthrie is the lack of a coherent release and distribution framework. There are several half baked implementations none of which have the full support of the community. Sure Erlang allows hot code swap, but it's mostly a manual process requiring a user to interact with the shell.

In my opinion, there are three main issues:

1) The Language actually is not general purposes. Or at least it is not promoted this way. If you really need Actor based model and lightweight threads, you can choose Scala/Akka, that is also well suitable for a wide range of different objectives.

2) Standard library(I mean OTP) is simply ugly.

3) Language's syntax is ugly too. Pascal again? No, thanks. :) I know there is Elixir that fixes most of the issues, but too few people know about it outside of the Erlang community. When someone mention Erlang he/she probably thinks about "vanilla" Erlang, which is ugly again.

P.S. I had been using Erlang for a while and then stopped.

I've tried using Erlang once or twice. I inherited an open source project written in it, wanted to maintain it a bit but I couldn't make head nor tail of it, and I'm a good programmer (but very busy with other things). There were too many things to learn to get started working with the Erlang ecosystem and I didn't really have the time.

I didn't find any good tools.

The error messages were obtuse.

I didn't understand how simple shit like configuration files worked. I couldn't find any place where the file was 'opened' from code. I chalked it up to the magic of the underlying framework or whatever.

    * Compiler for a scheme-like language in Haskell
    * simple webapp in Haskell using Yesod
    * small 2d game in Clojure
    * racket-based little language that compiles to openscad
    * lots of academic programming-languages projects in Racket
      (garbage collector, type checker, prolog, etc)

Have never used it nor considered it.

The driving force behind most of the new languages I have adopted; is a friend with experience who plants seeds, then can offer support and answer simple questions as I am learning. I have no friends that I know of who use Erlang.

Since you asked: I have never tried Erlang because I've heard it's like Haskell but harder to learn, and Haskell already breaks my feeble mind, so I have steered clear. This may or may not be an accurate picture, but it was my decision-making process. I have no programming problems that make me think learning a whole new language would be worth it (on top of my existng stack of 10 or so).

It has a huge learning curve compared to many other languages.

Ask the simple question of how do you write the equivalent of

int main(....) { ... } and well... there isn't one!

You are almost forced, from the start, to learn about releases and a ton of other really complicated stuff just to write a program you can share. Its sort of being fixed with relx.

Secondly no one seems to understand pattern matching at first. Its just such an alien concept when you look at it compared to all the other mainstream procedural/oo languages people usually already know. Again a huge cliff to climb to really grasp the possibilities and usage.

It really is quite a great language, and an even better runtime. The learning curve to making great things with it is just quite high in my opinion. I've done two major projects with it, one shipped as an embedded web app in some lab equipment out there. I think it was a good choice!

Compared to other languages, Erlang has a huge learning gap between "playing around in the REPL" and "deploying an application". There's a much larger base of knowledge needed to deploy Erlang apps, than an equivalent app in another language such as Python or Java.

A language needs to get a foothold somewhere. Ruby started on the low end and worked its way into a position of power. Java started in the enterprise and became normal thanks to catering to their needs so well. Erlang is in an awkward place where it solves certain problems well, but there is not a big class of user for it to get a foothold in. It's not better than Ruby at bring Ruby and it isn't better than Java at being Java and it isn't better than C at being C.

Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that one can not imagine being translated back into the Algol-esque framework. Lisp does things with its bizarre syntax, making it obvious how to write correct macros and being homoiconic, which translates poorly back into Algol-esque infix languages. It's almost inconceivable that one could translate a concatenative program back into Algol-esque syntax [2]. But Erlang really doesn't do anything that couldn't be in Algol-esque syntax. (Near existance proof: Go. Yes, there are significant differences, but the two are inter-transliterable to a much greater degree than any pairing of any of the previous sets of language families.)

If it had an Algol syntax, and performed the SSA transform behind the scene, it would probably be very, very big now.

Bear in mind as I say this that I'm not necessarily advocating for those changes. For instance, this would require some tweaks to the semantics of pattern matching, too, which aren't necessarily for the better... in the abstract. However, they probably would be for the better in terms of usage.

I'm pretty sure Go is going to eat Erlang. Erlang programmers will 100% absolutely correctly complain that OTP can't be translated without loss into Go, and almost nobody will care. Again, I'm not necessarily advocating for this, because the Erlang advocates will be right, you just can't quite get it fully expressed in Go and that saddens me, it's just what's going to happen, I think.

In fact I'm doing it myself; the Erlang core of my system is getting pulled out and replaced by Go for a variety of reasons, and one is despite the fact my team is fairly adventurous over all, we're still better off finding people to work on Go than Erlang. (In the next couple of months I hope to release my first release of "reign", "Rewrite Erlang In Go Nicely", which brings some of the Erlang stuff into Go for the purpose of porting existing programs. I've been pulled into other fire fighting so I'm not on it this second, but I'll be getting back to it soon. That implements Erlang-like mailboxes and network clustering, and I've got a supervisor tree implementation on deck for Github too. Subscribe to https://github.com/thejerf to see when those come out in the next couple of months.)

By the way, Erlang advocates, bear in mind that trying to argue me out of this position is a waste of time. I've been programming in Erlang for 7 years now. I get the syntax just fine, even if I still don't like it. The problem is that you have to argue the greater programming community out of this position, and I don't think you have, and I really doubt you can. For better or worse, being non-Algol seems to put a hard limit on your general-purpose programming acceptance. (In my opinion, that is for the worse, but here we are. Again, please don't mistake this opinion as celebration of any of these facts. My opinion is that Erlang deserves better. My belief is that it won't get it.)

[1]: That's pretty much every modern mainstream language today: C(/++/#), Java, Python, Javascript, etc. Not all those languages come from the same semantic heritage (scripting vs. conventional OO manifest types being one big example), but they come from the same syntactic heritage. Contrast with the ML family, the Lisp family, the Prolog family (which is pretty much just Erlang now), and the Forth family for different syntactic heritages.<...

  select {
     case: foo := <-fooCh
       fmt.Printf("got %v\n", foo)
     default:
       fmt.Println("got nothing")
  }

Erlang requires a fair amount of boilerplate for a small project (rebar, app file, application behaviour, gen_server behaviour, etc.) and escript doesn't work very well.

It lacks a good way to do abstract data types (records don't count).

The compiler's ability to optimize is limited by the lack of purely functional guarantees and the metaprogramming facilities (parse transforms) aren't easy to use to work around that.

There's no facility like Haskell's ST or clojure transients to encapsulate mutable stuff, just a hole to write code in C and who really wants to do that? Yes, I know about the process dictionary and ets but those aren't appropriate for most algorithms I've wanted mutability for.

That said, I still use Erlang, but only in the domains where it really shines.

Coming from Haskell, the actor model does not seem composable. The state machine style is interesting, but the pattern that it comes out as distracts from the concept / algorithm.

This comes from reading rabbitmq and riak-core sources.

Like Clojure, I like that Erlang has lots of interesting ideas. I may never use either in production, but Erlang's OTP sounds very interesting as a way to handle real-world scenarios like failure handling. Similarly, Clojure's datomic, core async, etc. are interesting ideas, implemented by people with good taste.

However, too many examples show trivial things like mapping over a list or calculating something recursively. As a professional programmer, I get how those things wrok. What sets these languages apart from Javas of the world is how state is handled. It isn't easy to dig through tutorials and docs to find the best way of keeping state, updating it, referencing it, etc.

I once attempted to implement a small order matcher (from the stock trading world) in Erlang. I know how to do it in imperative languages, but it was pretty painful to do so in Erlang. It was getting very verbose, I wasn't sure how to create a priority queue, how to modify elements in a data structure, etc. Since this wasn't a simple transformation of data, I had a hard time finding references in documentation spread across the web.

I realize that if I was committed to learning Erlang, I would work through a book or two. Perhaps find a small open source project and work through the implementation. However, I, like so many others, wasn't committed. I was merely trying it out and when I couldn't make progress, I decided to use my precious free time on something else.

As an everyday language, it seems too different to get used to. As a language you learn to expand your horizons, it's not weird/different enough when compared to e.g. Haskell and Lisp.

Also, Erlang has long had an excellent reputation for performant, parallelizable code, but Go and node.js have stolen some of their thunder on that front. (I'm talking purely marketing-wise, I don't know enough to compare them technologically speaking.)

I'm not sure if "no platform / no package manager" really matters.

People first learn a language and get excited about it, and then if something irks them, they'll scratch that itch. It's like that famous de Saint Exupéry quote: "If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."

The node.js ecosystem was absolutely awful at first, and the deployment story really only got fixed about a year or longer after the first release of NPM.

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).

Before finding Clojure I dabbled in Erlang. In the end I found the "share nothing" model to be too limiting. Sure its great for highly fault-tolerant systems. But the fact is I just don't need that most of the time. It's just easier to setup a AWS autoscaling cluster of web servers running Clojure and be done with it.

Oh yeah, and Clojure beats the pants off Erlang when it comes to performance. Even Erjang is faster than stock Erlang.

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.

Erlang is meant to be high-availability and high-performance language. Good. It has potentials.

However, I cannot build any high-availability and or high-performance system based on it because it lack community around it. I.e., if something stops working there is very little resources or support - I'm not even sure if anybody tried or tested that.. So it is chicken and egg problem :(

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.

Erlang is dogmatically functional and smells of prolog. Most people don't know what to do with it.

I love reading all these posts about new cool-kid concurrent languages when Erlang has decades of maturity and a sophisticated scheduler that kicks the shit out of go/rust/scala/insert cool new thing.

Source: I've used it professionally and its my language of choice

Doesn't run on CLR/Mono.

I haven't looked at Erlang before, so I thought I give it a quick look. Google led me to the Erlang home page[1], which has "What is Erlang" (sounds good) and "What is OTP" (which doesn't bother to define what O, T, and P stand for.)

Following the Erlang Quickstart [2] link, I get a page that doesn't really tell me anything about the language. It demonstrates a program that implements a factorial function, then tells me to go write games. Other than "Burn the CPU", I'm not sure what kind of games I can write with what I learned here.

The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end. The second link goes to an online reference guide [3] which seems more promising, until I read the introduction [4]. Under "Things Left Out" is "How to communicate with the outside world". Hrm...

So, what I have so far is that Erlang is a functional language, and that the online reference doesn't cover interaction with anything outside of your program. Based on this I'm guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not. Yes, I'm making a big inference here, but that definitely seems like where I'm heading.

So I'm going to stop here, and do some real work in a pragmatic language.

[1] http://www.erlang.org

[2] http://www.erlang.org/static/getting_started_quickly.html

[3] http://www.erlang.org/doc/getting_started/users_guide.html

[4] http://www.erlang.org/doc/getting_started/intro.html#id62800

    * code sample on landing page  
    * comprehensive tutorial linked directly from landing page

    * no code on landing page  
    * "quick start guide" which is basically a link to a non-free book 
    * Getting to actual code requires 3-4 clicks from the landing page
    * e.g. Documentation -> Course -> Sequential Programming

My theory: writing network servers that are not web servers is a relatively uncommon problem to have these days.

One of the hardest parts about learning a new language is coming up with a learning project that showcases the unique strengths of the language without being intimidating to a newcomer or too contrived to actually be useful. This is difficult in any language, but it's especially so in Erlang.

Obviously "it's different; people don't like things that are different" has a lot to do with it, but we've seen other FP languages experiencing faster growth recently, so I don't think that can be the only cause.

I've been using it for a few months, for what it's worth.

Edit: obviously there are lots of people who need to write concurrent network server clusters, but I'd argue that the benefits of the Erlang approach are difficult to grasp before you've actually deployed something written in Erlang; simple toy projects (which are a prerequisite to learning a language) don't usually play to its strengths. A language that's really good at web apps is going to grow more quickly simply because its advantages are easier to appreciate from the start.