The Artima Developer Community
Sponsored Link

Java Community News
Damien Katz Critiques Erlang

5 replies on 1 page. Most recent reply: Mar 14, 2008 1:31 PM by Vijay Kandy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Damien Katz Critiques Erlang Posted: Mar 12, 2008 6:34 PM
Reply to this message Reply
Summary
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.
Advertisement

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?


Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Damien Katz Critiques Erlang Posted: Mar 13, 2008 9:41 AM
Reply to this message Reply
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'...

Vijay Kandy

Posts: 37
Nickname: vijaykandy
Registered: Jan, 2007

Re: Damien Katz Critiques Erlang Posted: Mar 13, 2008 7:12 PM
Reply to this message Reply
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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Damien Katz Critiques Erlang Posted: Mar 14, 2008 9:33 AM
Reply to this message Reply
You can always use message passing between Java objects, using a synchronized list; just make sure you clone all the objects, or that the shared objects do not change state.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Damien Katz Critiques Erlang Posted: Mar 14, 2008 12:11 PM
Reply to this message Reply
> You can always use message passing between Java objects,
> using a synchronized list; just make sure you clone all
> the objects, or that the shared objects do not change
> state.

This is an excellent design that I've learned and used. I prefer a Queue to make sure that things happen in order. Many timing / synchronization bugs could be fixed by adding another queue.

Vijay Kandy

Posts: 37
Nickname: vijaykandy
Registered: Jan, 2007

Re: Damien Katz Critiques Erlang Posted: Mar 14, 2008 1:31 PM
Reply to this message Reply
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.

Flat View: This topic has 5 replies on 1 page
Topic: Supporting Fixnums in the JVM Previous Topic   Next Topic Topic: Image Manipulation in Flex


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us