Damien Katz is lead developer of CouchDB, a non-relational document database, and one of the most visible open-source projects using Erlang. Based on his experience using the language for CouchDB, Katz reviews some of his Erlang grievances in a recent blog post.
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.
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:
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?
This is a nice example of why some languages have failed to grab attention. ML, Haskell, Erlang, etc may have some nice academically endorsed features, but a programming language is a lot more than the lambda calculus.
Unfortunately, people don't listen. When you tell them the problems with their favorite language, the reply is 'la la la la la'...
I am a Java developer and use Java/JEE in my day job but I use Erlang for a personal project. What I like the most about Erlang is that it has processes and they don't share variables. Java threads can share instance member variables (among other things) and this brings a lot of headaches. Take Servlets for example. Servlet container creates 1 instance of a servlet and allows multiple threads to share the same instance. You can use semaphores/wait/notify/synchronized/instance locks/class locks etc but you don't need any of these workarounds in Erlang. Message passing and the receive-> construct are the best and I don't understand why none of the newer languages copied these features. Messages can be passed to a process with a simple ! operator! What I like the least is the use statement terminating characters. Unlike Java where all statements end with a ";" Erlang statements end with different characters depending on where the statement is in the source file.
Java 5's BlockingQueue classes made the job easier. I think they are the closest to Erlang's receive-> construct. But the cool thing about receive is that it automatically creates the queue of objects and blocks until a message is picked up - a lot fewer lines of code.