4 ms·

Nitrogen 2.x Released (Erlang Web Framework)

44 points by chops 17y ago

chops 17y ago
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!
Ixiaus 17y ago
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 17y ago
  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 17y ago
Well, I am now working on one project adopting nitrogen, thanks for the hard working. Really enjoy the event driven programming style
cageface 17y ago
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?
- hasanove 17y ago
  Performance (even on single machine) would definitely be one of the significant advantages.
  - daleharvey 17y ago
    performance in erlang is generally described as "good enough", its often one of the reasons not to use erlang.
- mononcqc 17y ago
  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.

44 points by chops 17y ago

chops 17y ago

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!

Ixiaus 17y ago

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 17y ago
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 17y ago

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

cageface 17y ago

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?

hasanove 17y ago
Performance (even on single machine) would definitely be one of the significant advantages.
- daleharvey 17y ago
  performance in erlang is generally described as "good enough", its often one of the reasons not to use erlang.
mononcqc 17y ago
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.