Ask HN: Why isn't Erlang more popular?

[gordonguthrie]

The old Erlang mailing list/twit o'sphere is in a fluster. A manic phase: “WhatsApp - they'll no be asking who uses Erlang now!" preceded by a depressive phase "why isn't Erlang more popular?".

The Erlang community is the last place with insight into why Erlang is not popular.

So lets ask people NOT in the community. Here is a list of hypotheses.

Erlang is not more successful because:

* OTP means Open Telephony Platform

* Erlang/OTP is run by Ericsson

* the syntax is prolog-y & not c-y or ruby-y or python-y, its just too damn erlang-y

* no package manager

* no list of open source packages

* no community site

* the mailing list is the community

* everyone knows each other from Stockholm

* it is too hard to get a first working app

* lists for strings, aargh!

* no for loops, eek!

* variables don't vary, whimper!

* people don't learn OTP first but start with Erlang

* people don't learn Erlang first but start with OTP

* no docs

* too many docs but it is the wrong sort

* not enough teaching materials

* doesn't run on the JVM

* we used to think that it was because there were no books...

* Erlang Solutions isn't a proper internet company

* the language develops too slowly

* emacs is the IDE

Some things people are pinning their hats on:

* more books, yay!

* WhatsApp!

* Elixir is irresistable to Rubyists

* LuvvieScript will prove irresistable to the JSers (disclaimer, I'm lying)

* FP is trés, trés à la mode

* LFE & Joxa will be the little lisps that can...

* something will turn up

* something better turn up

* oh God, get me another drink, even at Stockholm prices, I'll be here when something turns up, but by God, a feed of strong drink is the only way to endure the wait

It would be helpful if you would say if you have:

* never used Erlang nor considered it

* tried it & stopped

* use it regularly

So fire away. Do your worst. Hold nothing back.

[jaimebuelta]

Erlang is a very specialised language. It does one thing well (scalability) at the expense of not really being a general purpose language.

The syntax is just weird, not only in a paradigm-way (pattern matching is not huge in most languages, but, hey, that's the way of doing stuff in functional programming), but on strange places ("read" lines ending on dot, semicolon takes time, it does not share any common syntax definitions with the languages used by 99% of the programmers). That sets a high bar in approaching the language, so it's difficult to "play around" with it (at least compared with other languages)

While I like some of the advantages of Erlang, the lack of general support for a lot of common operations (and yes, string manipulation is a huge deal) and the fact that it is designed with a very very particular problem in mind makes it "a silver bullet". Not in the usual meaning, but in the way that's only useful for killing a werewolf. For every other task is too expensive and just not the proper tool. I was involved in a project that used Erlang for something not well suited for it, and it was absolutely awful, you have to wrestle with it to perform common stuff that in other languages is done by the standard library. Again, you win something, but only in a very very VERY specific problem.

(I've used it in another project when it was the proper tool, and, in that case, it's still not the most pleasant experience, but you're getting a clear win)

[timje1]

This. It's amazing and powerful if you need 1m+ client connections per server. Outside of the epic scale engineering problems of facebook, twitter, google, amazon, whatsapp... It's very difficult to get anything done with Erlang.

If you have fewer than a million people using your application at a time, you're probably better off writing it in a more normal language.

[DougWebb]

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

[vertex-four]

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

It was actually designed to solve actual problems. Specifically, extremely high reliability in some of Ericsson's core networking gear.

I'd recommend Learn You Some Erlang[0] if you intend to look at it again. It explains the language, then OTP (the Open Telephony Platform - a framework for defining Erlang process trees and failure modes), then basic outside communication and disk storage.

[0] http://learnyousomeerlang.com/

[asattarmd]

Ffs, you're not looking at some small product that an unknown company built. You're looking at something that is really well-known. What does the website of Google convey? Do you really decide whether you'd learn a language by looking at its website?

> "that the online reference doesn't cover interaction with anything outside of your program" This does NOT mean it does not teach you IO. The full bullet point is

> "How to communicate with the outside world and/or software written in other languages (ports). There is however a separate tutorial for this, Interoperability Tutorial"

It means it won't teach you FFI in a tutorial.

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

I don't know how you got to this dumb conclusion when "What is Erlang?" on the main page clearly states:

> Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.

[TeMPOraL]

> (which doesn't bother to define what O, T, and P stand for.)

It obviously stands for Outlaw Techno Psychobitch ;).

http://www.youtube.com/watch?feature=player_detailpage&v=rRb... (Erlang The Movie II)

[mietek]

> The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end.

Why are you saying a link to Learn You Some Erlang for Great Good [1] is a dead end? Have you missed the "Read it online" button?

[1] http://www.learnyousomeerlang.com

[coldtea]

>The first link to more documentation at the bottom of the page goes to a book's website, so that's a dead end.

Well, you can read the book online, so how's that a dead end?

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

Well, $16B for WhatsApp, for a company with like 40 engineers, proves that Erlang can be quite pragmatic itself.

[Luc]

Come on. Not exactly a good faith effort, is it? Why type in a rant like this, when you could have found a wonderful tutorial on Google in one tenth of the time it took you to write this?

[technomancy]

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.

[dnqthao]

that's exactly what was my thinking also.

[lincolnq]

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.

[parallelist]

Are you a good programmer in imperative languages only by any chance?

[pbnjay]

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.

[arh68]

Popularity is probably the worst metric for a programming language. Programmers conflate popular for good pretty often. They line up often, but they are orthogonal. The original question is loaded. Why not ask "What usually increases a language's popularity? How can these effects be applied to Erlang?"

Now the answers are a bit more useful, a bit more constructive:

* write more, better docs (Erlang for Java programmers, .. for JS devs, .. Ruby, etc)

* polish the websites, improve search rankings for helpful links (the standard library, etc)

* write at least one good O'Reilly book

* write lots of libraries, especially web frameworks

* integrate seamlessly with other platforms (possible with Clojure, maybe not Erlang)

* upload screencasts "15 Minutes in Erlang", etc

* ...use your imagination

Lisp is another prototypical "our language is awesome, why is it dying?". FreeBSD used to get joked on, too. Well la-dee-da, Erlang on FreeBSD can be a winning combination! These technologies will remain good, but they won't magically make themselves popular. It's not if-you-build-it-they-will-come anymore. There are too many programming languages to get acquainted with even 20% of them. Languages need to be more competitive to be more popular.

[JackFr]

Marty DeBergi: I was just wondering, does this mean uh...the popularity of the group is waning?

Ian Faith: Oh, no, no, no, no, no, not at all. I just think that their appeal is becoming more selective.

[gordonguthrie]

I wrote the question and I agree that popularity isn't a good metric (on its own). But it is a valid metric, in the round. Making a language more popular has to start with people who don't use it though, so no apologies for being a bit populist in my phrasing...

[redthrowaway]

Fun fact: I did a co-op at Ericsson in second year. I asked my interviewer (later boss) if they used Erlang at all, and she'd never heard of it. Some of the hackers in the company had a limited degree of familiarity with it, but none of the PMs/managers seemed to know what it was.

[Kiro]

If you search for Erlang on their jobs page you get 17 results, most which are in China and India. In comparison Java gets 183 results.

http://jobs.ericsson.com/search/?q=erlang

http://jobs.ericsson.com/search/?q=java

[vq]

It was even banned internally for a couple of years and Armstrong left Ericsson as a result.

I know it gets some use within Ericsson for running quickcheck tests against C-code.

[hapless]

Something Erlang fans rarely mention: only one generation of equipment used the OTP.

In other words, it was stillborn.

[cia_plant]

I think the majority of programmers are very conservative about language, they use whatever they already know, be it Java, C#, C++, ruby, etc.

A minority are more fashion-driven - if something seems like the hot new trend they'll jump on it, scoffing at the old-fashioned crap their coworkers are using. Erlang unfortunately is not fashionable, and it's hard to predict or control fashion.

A smaller minority are driven by some concept of technical merit. However, once you've strayed from the safety of Java/C#/etc., it seems like you might as well go all the way and get into Haskell, which is pretty widely seen as the most advanced, mind-expanding, powerful, futuristic programming language right now, and for good reason.

[codygman]

"once you've strayed from the safety of Java/C#/etc., it seems like you might as well go all the way and get into Haskell"

This is exactly what has led me to Haskell. I was doing Python but got interested in Go for Channels and Static Typing. It turned out Go's static typing was a little to weak for me, so it's unsurprising that I came across Haskell shortly thereafter.

[gordonguthrie]

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

[gcb0]

If you skip the syntax part and the "query" pet peevy, it is as if he was reading my mind! Spot on

The string part specially... will have to check out his binary string code.

[thedufer]

I haven't used or looked at Erlang, but bear with me.

* no package manager

This is _huge_. For example: I currently work very heavily with node.js. I understand all of the many, many problems with javascript. NPM single-handedly makes up for all of them put together, in my eyes.

Which is to say - an amazing package manager can make a poor language. A decent package manager (pip, for example) allows a nice language to shine, but won't make or break it. Lack of a package manager could probably kill just about any new languages these days (and Erlang - correct me if I'm wrong - appears to have the popularity of a pretty early-stage language right now).

[rhizome31]

This is a really good point. There's an attempt to tackle this with Elixir: http://expm.co/

[mindjiver]

This. I work at a big Erlang shop and the "dependency handling" is either git submodules or rebar which is glorified submodules. I think this is due to packaging not being sexy enough to work on, much more fun to think about the internals of the Erlang VM.

[gordonguthrie]

And old language that looks like a young one... hmm, interesting...

[captainmuon]

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

[501]

I've posted these before[1]:

* No public bug tracker

* epmd's security (or lack thereof)

* Can't insist that epmd be started separately (`erl -no_epmd` won't start epmd but it also won't start epmd's gen_server)

* Can't swap out epmd because while `erl -epmd_module foo` is there, `net_kernel:epmd_module()` is barely used. (Although I don't think its interface is documented anyway)

* No built-in way to hook UNIX signals

* While the documentation itself is pretty good, it's presentation is lacking and it's difficult to quickly correct mistakes as you run into them

* It can be difficult to reason about when a shared binary will be garbage collected

* OS packaging (I'm thinking of Debian/Ubuntu) of Erlang and Erlang apps tends to be more harmful than helpful (old packages, namespace conflicts, etc)

To them I'd add:

* No agreed upon build tool (rebar while prevalent isn't universally accepted)

* Community libraries often have no support for upgrades or aren't packaged properly for releases

* Can't upgrade SSL if you're using it as a carrier

* No standard code format tool like gofmt (yes I know about erl_tidy, no it doesn't provide the same functionality as gofmt or it'd see similar use)

* Not enough infrastructure around built around edoc; where's the godoc or godoc.org work-a-likes? (yes I know about erldocs.com, it's no godoc.org)

[1] https://news.ycombinator.com/item?id=5801706

[gordonguthrie]

Interesting set of comments...

[jerf]

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.

[2]: http://evincarofautumn.blogspot.com.es/2012/02/why-concatena...

[jared314]

The syntax issue is why I think the Elixir programming language[1] has a good chance of improving the ecosystem around the Erlang VM. Although, most Erlang programmers, who i've spoken to, feel the syntax is a non-issue, so it is more likely to convert programmers who are new to, or curious about, Erlang.

It is also worth a note that Elixir adds language features, such as default UTF8 binary strings, real macros, Clojure-style protocols, tooling, etc, on top of the Ruby-style syntax.

[1] http://elixir-lang.org/

[davidw]

I think this is mostly right. Erlang is, roughly, in the Lisp, Forth, Smalltalk bin, not the C, Ruby, Go bin. Its advocates are going to be going on about how "Erlang got that right in 199something" for years, even when things like Go have got most of what it has.

I wrote about Erlang 7 years ago, and a lot of that still holds true, IMO:

http://journal.dedasys.com/2007/09/22/erlang/

That said, I lately helped start a pretty big project in Erlang and have been using it a lot lately. It has improved, and it's a fun language to use in a lot of ways.

[Jtsummers]

> I'm pretty sure Go is going to eat Erlang.

I wouldn't be surprised by this. Go's concurrency pattern is fantastic, but to match what Erlang does it needs to be easily extended beyond the running process. Can channels connect multiple "nodes" yet? That is, two running go programs, can they communicate via channels or do they have to use some other IPC mechanism? Across a network? That universal communication structure is (IMO) erlang's killer feature.

[Nogwater]

Not knowing enough about Erlang/OTP or Go: Would it be possible for more of OTP to be replicated in a Go 2.0? What's missing? What would it take? What can never be replicated?

[pstuart]

I'm looking forward to see how reign turns out!

[paperwork]

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.

[jamii]

I spent a total of about 11 months (spread over a few years) consulting on a betting exchange in erlang. It was pretty painful even with lots of erlang experience.

I sat down one week and prototyped a rewrite of the core exchange in clojure. 40x better throughput and 10x better latency despite using only two threads, naive `pr-str` serialisation and storing all the exchange state in one huge immutable data structure (for easy rollback on errors). Much easier to debug and to wire up different setups without modifying code (eg swapping out the network layer without touching the io and batching code).

There are some interesting ideas in erlang but they are hidden behind an inexpressive language and poor libraries. I would think more than twice before taking on another large erlang project.

[swvist2]

I have tried it and (try to) use it when appropriate. I am fairly comfortable with it and my only disappointment is that I do not get to use it often.

The ability to solve a problem in a particular programming language is often dependent on the ability to express the problem in the constructs provided by the language. A very good example is the problem of concurrency. Doing something concurrently in a primarily procedural/OOP language often seems hacky and it is something that does not feel natural. The actor model that erlang implements is a very powerful model for certain class of problems and concurrency is one of them. Erlang the language, minus the OTP, is extremely small and once you get over the culture shock experienced when it comes to syntax, things will seem pretty easy. OTP isn't magic. Its years and years of erlang experience packaged into one neat library, solving commons problems, so that you can concentrate on your work instead of reinventing the wheel.

Reading Joe Armstrong thesis 'Making reliable distributed systems in the presence of software errors'[1] is highly recommended if you want to understand why things are the way they are.

[1] : http://www.erlang.org/download/armstrong_thesis_2003.pdf

[eliah-lakhin]

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.

[astine]

Learning Erlang has been on my todo list for years now. I know Java because I was exposed to it in school and had to use if for work. I know Perl because I've had to use it for work. I know C because I've had to know it for projects and some work. I know javascript because I have to. I know Common Lisp and Clojure, because I want to.

Erlang belongs in this category of languages that have really cool features but which almost nobody has to learn to do a certain job. Nearly everything you can do with Erlang you can do with something else and there are a lot of languages that are necessary for one purpose or another and can't be replaced with Erlang. This is usually because said language is so entrenched in a space that it doesn't make sense to use anything else.

The end result is that programmers only have so much time and only so many projects that they can reasonably devote to their 'fun' language and there are a lot of those from which to choose. Erlang isn't competing with Java, it's competing with Lisp, Smalltalk, Factor, Haskell, OCaml, etc. That's a long list of competition.

[_halgari]

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.

[dwb]

I really think moaning about the syntax is a bit pathetic. It's not what most programmers are used to, sure, but it's hardly Malbolge, is it? If Erlang/OTP is a good fit for your problem, use it. Learn the syntax. It's really not that hard.

[rvirding]

I am not going to enter into a syntax argument I have already given my views on that here http://rvirding.blogspot.se/2014/01/erlang-syntax-again-and-... . My main point is that the syntax is simple and that it fits the semantics much better than anything based on an Algol like syntax would, even one which uses ';' in the "normal" way.

And one reason it works is because it has built-in those features for building fault-tolerant systems which, for example, Go lacks. Borrowing from NASA "Failure is not an option".

[davidw]

> And one reason it works is because it has built-in those features for building fault-tolerant systems which, for example, Go lacks.

Very few people really need that though, so from a marketing point of view, to sell that as the primary feature is to consign Erlang to a fairly small niche.