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?
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 :)
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.
the combination of functional programming (and even single assignment) along with a mature set of behaviours for handling errors in processes makes for a really pleasant programming experience.
Of course erlang is nowhere near as mature/popular in the space of CRUD web programming as php/ruby/python and to use it for that you can hit a few basic walls where you would have expected a solution to be waiting, but when you need to do more than read/write a database for each request then erlang really shines
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.
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.
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).
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...
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.
Can somebody with more experience make the case for me?