One of the more visible open-source projects using Erlang as its core language is CouchDB, a networked, non-relational document database. CouchDB used C first, but then switched to Erlang due to the language's excellent concurrency support.

In a recent blog post, What Sucks About Erlang, CouchDB lead developer Damien Katz reviews some of his criticism of Erlang, especially in the context of using the language for CouchDB.

Noting that,

Erlang is amazing in ways it would take a whole book to describe properly. It's not a toy built to satisfy the urges of academics, it's used in successful, real world products... But there is a good chance that Erlang just is not a good match for your uses...

Katz lists several of his complaints about the language. One of those complaints, for instance, centers around Erlang's lack of sophisticated support for organizing code:

The only code organization offered is the source file module, there are no classes or namespaces. I'm no OO fanatic (not anymore), but I do see the real value it has: code organization.

Every time time you need to create something resembling a class (like an OTP generic process), you have to create whole Erlang file module, which means a whole new source file with a copyright banner plus the Erlang cruft at the top of each source file, and then it must be added to build system and source control. The extra file creation artificially spreads out the code over the file system, making things harder to follow.

What I wish for is a simple class facility. I don't need inheritance or virtual methods or static checking or monkey patching. I'd just like some encapsulation, the ability to say here is a hunk of data and you can use these methods to taste the tootsie center. That would satisfy about 90% of my unmet project organization needs.

While Erlang is often mentioned as a language that makes it easy to write fail-safe programs, Katz notes that fail-safety is something developers have to build into their applications:

With CouchDB we discovered the hard way how Erlang handles memory allocation errors from the OS:

exit(1);

When the VM cannot get memory from the OS, it just commits hara-kiri. It doesn't just kill the virtual Erlang "process" that needs the memory. It kills the whole VM, taking along any child OS processes with it. But at least it's an honorable death...

So no problem you might think, given Erlang's robust, fail-fast and restart nature, it will restart itself automatically and barely miss a beat. Well, that's what I thought, but then I'm generally a positive guy.

Nope, Erlang won't restart itself automatically, that's something you have to build all by yourself. The only solution we've found is to create a parent watchdog process to monitor the VM and restart it if it crashes.

Katz also points out several syntax issues with Erlang, such as the use of varying statement separators, cumbersome if expressions, and hard-to-work-with string handling:

Unlike the C and Algol based languages, Erlang's syntax does away with nested statement terminators and instead uses expression separators everywhere. Lisp suffers the same problem, but Erlang doesn't have the interesting properties of a completely uniform syntax and powerful macro system to redeem itself. Sometimes a flaw is really a strength. And sometimes it's just a flaw...

You might think if branching as something that no language could ever get wrong. Doesn't seem possible does it? I was young once too... The first problem is that every time an if executes it should match at least one of the conditional expression branches. When it does not, an exception is thrown... Erlang ifs could be so much more useful if it would just return a sensible default when no conditionals match, like an empty list [] or the undefined atom. But instead it blows up with an exception. If Erlang were a side-effect free functional language, such a restriction would make sense. But it's not side effect free, so instead it's idiotic and painful... How can a language have butchered the if and still be useful? Well, fortunately case expressions in Erlang are powerful and damn useful, and a decent substitute for most uses of if...

The most obvious problem Erlang has for applications is sucky string handling. In Erlang, there is no string type, strings are just a list of integers, each integer being an encoded character value in the string... Erlang string operations are just not as simple or easy as most languages with integrated string types. I personally wouldn't pick Erlang for most front-end web application work. I'd probably choose PHP or Python, or some other scripting language with integrated string handling...

In addition to the above points, Katz also laments the relatively static nature of records, as well as the difficulty of writing good functional-style programs in Erlang.

If you've tried your hand at Erlang, what do you think of the language?