Nitrogen 2.x Released (Erlang Web Framework)

Performance (even on single machine) would definitely be one of the significant advantages.

The advantages of Erlang are not limited to distribution, but also excellent concurrency. By this, I don't necessarily mean high throughput and amount of queries served per second, but a general resilience over high loads.

Because every task can be broken into bits running concurrently (note: not necessarily in parallel, just concurrently) and because the Erlang VM has full control of the runtime, there is a general good load balancing where the applications remain responsive (although slower) over high load, rather than just dropping calls.

Another part comes from the high reliability. Of course a broken app is annoying. Fortunately, there are a lot of technologies with stuff like load balancers and whatnot that make it easy to scale in any language and deploy new releases without downtime no matter the kind of code you use. By doing this, the burden of high reliability and scalability is often moved to the database layer. An Erlang web app won't shine that much from this perspective -- the DB might do the heavy lifting.

However, the way exceptions are handled with Erlang and its supervision trees changes the way you write programs. You only program for the cases you know how to handle. For the others, you "let it crash." This is a bit weird at first, but what this really means is "only fix the errors you know how to fix" -- the runtime is made to support living with the other kind of errors.

The other aspect of using concurrent actors to do error management is that it shifts the perspective of where exceptions are to be handled. In most languages, exceptions are managed from within the execution flow of the program:

               main
        (top level try catch)
                |
            some code
        (might catch errors)
                |
          deeper calls with
         own error management

The problem with this is that your regular code needs to handle outstanding errors on every level or you just delegate the burden of making things safe to the layer above until you end up having the eternal top-level try catch (it's more complex than that obviously). Erlang supports this model too. However, it also supports supervision trees, which change the structure in the following way:

     some actor   ------------------- supervisor
           |                                     > supervisor
       some code  <--> other actor -- supervisor
           |               |
     deeper calls      more calls

(I hope the drawings are clear)

Here what I mean to illustrate is that actors who run code are being supervised by other concurrent 'supervisor' actors who are dedicated to handling errors that won't be handled by 'worker' actors. They can restart dead workers, notify the user or a logging system of a problem, propagate the killing of workers to dependent ones, etc.

This means the burden of error handling is shifted from within your standard and correct execution path to a concept litterally parallel to it. This lets you organize your code towards non-defensive programming while keeping it more stable at the same time.

This is not to say standard exceptions are not the way. They're still pretty useful. However, there is more than one class of error that can happen in software, and I think Erlang deals with this beautifully.

In my opinion, this concept of supervision trees is what Erlang really is about. People come in for the concurrency, but they stay for the supervision trees.

I've not used Django or Rails, so I can't speak with respect to those languages, but I am a PHP developer (my primary income comes from sites I've built in PHP).

Erlang is a goofy language with it's goofy Prolog-based pattern-matching assignment syntax, and it's (mostly) immutable data.

What appeals to me about Erlang with respect to web development are a few things:

1) Web development is naturally multi-process, and Erlang's extremely lightweight process spawning lends itself extremely well to web apps (compared with the overhead of spawning a PHP process).

2) Erlang lends itself well to comet-style communication (and I can see a strong future using it with websockets), since having a running process with the sockets is very lightweight.

3) Using the message-passing to communicate with some kind of backend application of some sort (in my case, I use it to communicate with a game-server backend also written in Erlang). Having the ability to use message-passing to almost trivially communicate with other connected users brings a rather interesting dynamic.

4) Erlang's general development philosophy of "crash early, crash often" combined with immutable variables makes debugging pretty easy.

Erlang isn't for everyone, but I think it's a great language. I enjoy it's goofy (and pretty terse) syntax. I'm no expert in it yet, by any means, but overall, I find it to be fun, and prefer functional programming to the alternatives.

But like I said, I'm unfamiliar with Rails and Django (I have a Rails book, but haven't gotten to it yet), so I can't speak comparatively.

Edit: mononcqc beat me to it, and also did a better technical analysis than me :)

Scant is a good word to describe the the state of the Nitrogen 1.0 docs. You definitely had to be willing to dive into the Nitrogen internals to find some things. The internal code was pretty easy to follow, so you could pretty easily figure out what you needed to do, but the external docs did indeed leave something to be desired.

I haven't played with 2.0 yet, since it's only a few hours old, but the docs do look a bit better so far.