Erlang Inside - Chad DePue - October 30, 2008
Nitrogen is the soon to be released Erlang framework for web development that uses an event based programming model similar to ASP.NET. Rusty Klophaus, the creator of the framework, agreed to answer some questions about Nitrogen and how he got started in the Erlang community.
This is the first in our series of Q&A sessions with the leaders of the Erlang community.
EI: How did you get started using Erlang?
R K: I started using Erlang in February 2008. I was setting out to build a distributed Web 2.0 application and had grown tired of OOP, and I was looking for something better. Like a lot of other people working on the edge of Web 2.0, when I heard what Erlang could do I knew that it was something special.
To understand why it’s special, you have to know a little about the history of the language. Erlang was born about 20 years ago–way before the Internet became popular–as a language for building telecom applications. Erlang was created out of necessity to solve a very unique set of problems at the time.
Today the internet is moving in a direction where more and more of today’s problems look like the problems that Erlang was designed to solve 20 years ago. For example, one of the biggest ways to gain a competitive advantage today is to change where your computation gets done. This could mean using Amazon’s EC2 or building your own data centers in the middle of nowhere. Managing this kind of distributed application can be a challenge in other languages, but Erlang makes it easy.
Erlang was clearly a better tool to solve these problems. Not perfect, but definitely better. And given that I had spent many, many hours struggling with these problems, Erlang’s ability to solve them so cleanly felt like magic.
EI: A lot of people say that Erlang is great for the back-end part of a system but that it’s better to use Ruby (via Rails,Merb, etc) or Python (via a number of frameworks) to build the UI, because Erlang is not good at string manipulation, makes simple methods where a loop would be handy more complicated than necessary, etc. The alternative is to use a more modern language and bridge the two with JSON, REST, etc. This is the approach that recent applications have taken. GitHub is probably the lastest example. Any thoughts on this critique of Erlang and any comments on how Nitrogen addresses these concerns?
R K: My intention had always been to build the back end of my company’s technology in Erlang, and to build the front end in Rails. But, by the time I got around to writing the front end, I had just finished a wildly productive period of time with Erlang, and I couldn’t bring myself to slow down and go back into learning mode with Rails. Plus, the idea of having to bridge Erlang with something else felt risky, it’s an opportunity for breakage, bottlenecks, and other surprises. Finally, Erlang has a powerful ability to structure data very differently than other languages, and that’s something that you lose as soon as you push data across the bridge.
Nitrogen certainly reduces the need to hop into a different language for front-end work. But, because of string manipulation, unicode, staffing reasons, legacy code, or any number of other reasons, it may still make sense for some projects to only use Erlang on the backend.
I really see Nitrogen hitting two major demographics:
First, there are the existing Erlang users who want to write an application on the web, but want to keep working in Erlang. I believe that these are the early adopters who will provide the best suggestions and feedback, and who will push Nitrogen to become a better framework. Nitrogen gives this community the same Web 2.0 toolbox that other languages have had for a few years now.
Second, there are the websites who are butting heads against the limitations of their current languages, who come to Erlang to break through these limitations, and then who use Nitrogen because they hate the idea of a bridge. Both Nitrogen and Erlang have a number of problems to solve (like string manipulation and unicode support) before we can really attract this part of the community.
EI: Why did you use an event based design similar to .NET vs a MVC design like rails, struts, etc?
R K: Here is the short answer: I come from a background of ASP.NET
which uses an event driven model, so 50% of the answer is that I wrote what I know, and the other 50% is that I tried to follow the wood grain of Erlang as much as possible.
Specifically, when thinking about the grain of the language, here is what I was thinking: Erlang lacks a good string manipulation library, so it doesn’t lend itself well to having templated HTML views, I’d rather express the page as Erlang terms. Erlang doesn’t have objects, so a Model object would be a hack. And finally, Erlang’s pattern matching made it really easy to envision how events would work. The list goes on, but you get the idea. This all added up in favor of an event driven framework.
The rest of this answer may get me in trouble, but here goes:
I think part of the reason that people have seen such huge gains from MVC is because it forces code organization. It can be very easy to write sloppy code in a scripting language; that’s the double edged sword of making a language extremely productive for small tasks, it’s easier to hang yourself on the big tasks. So when MVC came along in Rails, one of the biggest benefits was that it gave developers clear direction on how to separate their code. Erlang, by it’s nature as a functional language, forces you to be a little more neurotic about organizing your code from the start, so for Nitrogen to impose MVC felt like an inappropriate and unnecessary constraint.
EI: What license do you plan on releasing Nitrogen under, are you looking for contributors, and when will it be released?
R K: Nothing is nailed down yet, but it will be one of the standard open source licenses that are out there. I will likely pull together the Erlang User’s Group of Arlington (find us on Meetup.com) and ask them, because many of those folks are much more heavily involved in the open source community than I am.
I will be looking for both contributors in terms of code, documentation, and general strategy. By general strategy, I mean that I’m not sure if the current technology stack that Nitrogen uses is right. Nitrogen currently uses Yaws as its back end HTTP server, and Prototype, Scriptaculous, and LiveValidate for client work. I chose Yaws because that’s what Yariv used for ErlyWeb (http://yarivsblog.com
) and I chose Prototype and Scriptaculous because that’s what Rails uses. I may swap out some technology down the road. The main principle will be to go with whatever has the fewest lines of code.
Nitrogen should be released around mid November along with some early documentation.
EI: Does Nitrogen provide database support similar to ErlyDb or do you assume people will be using Mnesia?
R K: Nitrogen doesn’t assume anything about your data other than giving you some convenience methods around binding records to elements on the page. So, you are free to go out and use whatever makes you happy.
I have not done much with ErlyDb or ErlyWeb, but my understanding is that ErlyDb exists for the same reason that ActiveRecord exists in Rails–Both ErlyWeb and Rails can auto-generate code for you based on your data model, and they use ErlyDb or ActiveRecord, respectively, as the generic data access logic in that code.
I think Nitrogen will head in this direction eventually. Down the road, I would love to make a Nitrogen screencast to compete with Rails’ “Creating a weblog in 15 minutes” demo. The only way for this to happen is to autogenerate code, and once this happens then Nitrogen will need it’s own ActiveRecord equivalent. That is many months down the road, though.
EI: Thanks Rusty - looking forward to experimenting with the framework!
Categories: Blogs Erlang Inside