

Nitrogen 2.x Released (Erlang Web Framework) - chops
http://nitrogenproject.com/whatsnew

======
chops
I've been using Nitrogen now for close to a year, and I've been anxiously
awaiting 2.0, particularly the improved support for multi-node servers.

I've got a couple of startup-type projects I'm working on that will be using
Nitrogen, though none of them are production ready yet.

Based on the documentation, it looks a bit easier to get up and off the ground
as compared with 1.0, since it looks like it can be packaged as a self-
contained system (packaged with the web-server and erlang binaries, if I read
that correctly).

Overall, I'm very excited about this.

Thanks, Rusty!

------
cageface
What are the advantages of Erlang for this kind of application compared to
something like Django or Rails? From what I can tell Erlang's syntax isn't as
nice for typical CRUD/string processing tasks and, unless you're doing some
kind of distributed web app, it's not obvious to me how relevant Erlang's
excellent support for distributed applications is.

Can somebody with more experience make the case for me?

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

~~~
cageface
Interesting. Thanks for the detailed response. When I rank about my current
pain points in web development smarter error handling isn't very high on the
list, so at least for the work I do this isn't a particularly strong selling
point. I can imagine for some apps it might be more important though. The ease
with which an Erlang stack could support Comet apps might be too.

The area in which I'd really like to see some new ideas is the impedance
mismatch between the DB, the business rules, and the HTML user interface. I
feel like at least half my code in a typical web app is just glue to make all
these layers behave consistently. Any platform that could make that more
natural would be very attractive.

~~~
mononcqc
Well, Erlang has its own database that can store Erlang terms (see mnesia). As
you can save some there for the impedance mismatch.

Nitrogen itself deals with reducing the differences between your backend code
and the frontend. See the demos and their source code for examples:
<http://nitrogenproject.com/demos>

Erlang also makes it a lot more easier to model stateful applications. I've
found the best way to make an active web app with Erlang is just to make a
regular application for the command-line (or the Erlang shell), and then add
bindings to a web-server.

Because every block of code you have is independent, this is really easy to
do. It makes every program extremely modular and I've rarely had the concept
of 'code reuse' come so easily.

Maybe stackless python could be an interesting option under this perspective
too, but I never used it for any project.

------
Ixiaus
This looks much more promising than the earlier version, last time it was far
too much of a pain to setup, docs were scant, and I didn't like the web server
interfaces that much.

Good job! I actually want to start playing with this now...

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

------
jacktang
Well, I am now working on one project adopting nitrogen, thanks for the hard
working. Really enjoy the event driven programming style

