Hello everybody! Thanks to Erlang Solutions I have been able to interview Evan Miller, one of the speakers you can meet at the upcoming Erlang Factory which will be held in San Francisco (21-22 March) . Evan is mostly known as the author of Chicago Boss. Let’s know him better with this interview! Hope you will enjoy it!
Meet the boss!
Paolo – Hi Evan, it’s really nice to have you here. Can you briefly introduce yourself to our readers?
Evan - It’s great to be here, and I’m glad to do it. I’m a graduate student in economics living in Chicago who has a passion for programming. People in the Erlang world know me as the creator of Chicago Boss, the
maintainer of ErlyDTL, and a loudmouthed defender of unpopular language features. Before grad school I briefly worked as an ops guy for Amazon.com and as a developer for IMVU, both out in Silicon Valley.
Paolo – How come a person with a degree in physics gets in touch with Erlang? Was it “love at first sight” or did you take a while in order to grasp it?
Evan - I stumbled across Erlang in a rather roundabout way. While I was involved in search operations at Amazon.com, I discovered that the source of almost all pain and suffering in the ops world can be traced
directly to blocking, threaded socket code. This led me to tinker with Nginx — a non-blocking server — but although I love programming in C (really!), I couldn’t stand the callback-based API. Shortly thereafter, a friend of mine at IMVU introduced me to Erlang, which is non-blocking… but without the callbacks! I instantly saw through Erlang’s syntax warts and fell in love with “what’s on the inside” – the absolute best VM for doing any kind of network programming.
As for the physics connection, I agree with Joe Armstrong — the creator of Erlang and who incidentally is an ex-physics person — when he says that Erlang’s process model comes naturally to anyone who has
studied relativity. Each process is its own “frame of reference”, in a manner of speaking — no process knows what’s on the inside of other processes, and heck, process clocks may be out of sync, but that’s OK!
You learn how to program around it and end up with much more reliable systems than ones that assume there is a “true frame of reference” of some sort. There can’t be, because you have to assume that *any*
server might fail or become unreachable in a networked environment.
Paolo – You are going to be one of the speakers at the next Erlang Factory held in San Francisco Bay area on March, what will be topic of your talk?
Evan - I am! The topic’s title is “Chicago Boss: a Web Framework Built For Comfort (And Speed)”. I’ll be giving a high-level overview of my pet framework and talk about some down and dirty details of why it’s designed the way it is.
Paolo – Who should attend your talk? Do they need to be expert Erlang or Web programmers?
Evan - Everyone should attend! I’ll try to make it interesting for both experts and novices. For example, I’ll explain why Chicago Boss is so darned good at fast server-side template rendering, which is something
that most languages have a lot of trouble with. I’ll also show some code samples to make things concrete.
Paolo – As the author of Chicago Boss would you like to introduce it briefly to our users?
Evan - Sure thing. Chicago Boss is a web framework that basically attempts to steal all of the good ideas from Ruby on Rails, and fix everything that’s broken: namely, slowwwwww templates, rampant RAM usage, lack of real-time messaging (WebSockets), and all this DevOps nonsense. So Chicago Boss combines fast templates with a clean API and a sophisticated “ORM”. I put that last bit in quotation marks because Erlang doesn’t really have objects, so we use a sort of fake object called a parameterized module that everyone on the Erlang mailing list hates with a passion, but which we love because it’s perfect for modeling data.
Anyway the framework is still in beta, but a lot of people are using it in production and we’re hoping to have a stable release soon!
Paolo – In your opinion, what are the main reasons that should make a web programmer switch from other platforms written in different languages as Rails, Symfony or Django to Chigago Boss?
Evan - Well, the first advantage is getting to work with a nice functional language like Erlang, even if CB sprinkles in some OO-style conventions here and there. Once you get the hang of it — which may take a while! — it’s generally easier to write correct code in Erlang than in non-functional languages.
But I think the real benefit actually comes down to operational costs — Chicago Boss runs smoothly on relatively little hardware and doesn’t need to be constantly restarted like most Ruby and Python servers. Erlang truly has a first-rate VM that is perfect for serving web pages. We’re really excited about running CB applications on ARM-based servers, which could really up-end the economics of server applications in the next few years.
Paolo – Chicago Boss in not the only option when talking about Erlang and web applications, what are the strength of Boss with respect to the others? Is there any feature you would like to “steal” from them?
Evan - CB is more of a full-stack framework than the others out there — in particular, it’s the only one that ships with any kind of database abstraction, letting you write your code first and choose from one of
six SQL and NoSQL database options later. There’s also an email server baked in, and an internationalization system — we’ve really tried to provide a complete package, whereas most of the other Erlang servers tend to be more bare-bones toolkits.
Don’t tell my mother, but I never hesitate to steal! But most of what I’ve stolen has actually come from the world outside Erlang. For example, the default template language is a tag-for-tag reimplementation of Django’s template language, and there’s now experimental support for the Jade template language.
Paolo – What kind of data storage support may we have with Chicago Boss? Do you recommend any of them, and if so why?
Evan - As I mentioned there are many options — in the SQL camp there’s PostgreSQL and MySQL; in the NoSQL camp there’s MongoDB, Riak, and Tokyo Tyrant, and then there’s an Mnesia adapter which isn’t SQL per se but it is schema’d. I don’t want to start a religious war, so I’ll stay quiet about my own preferences — but it’s really easy to add support for more databases — usually just requires a couple hundred lines of code.
Paolo – At the beginning Boss was implemented around Misultin, but later you moved to Cowboy. Was it difficult to switch the architecture? How many code did you rewrite in that sense?
Evan - For a long time, Chicago Boss supported only Mochiweb and Misultin; as we were pondering how to support Cowboy’s alien-looking API, someone had the brilliant idea to write a Mochiweb-compatible wrapper around Cowboy! It’s called “mochicow” and lets us adapt CB to use Cowboy in rather short order. Anyway, most of the hard work here is actually done by the folks over at Nitrogen who created SimpleBridge, which is an abstraction layer over I think six different web servers. It’s really a nice little library and we’ve contributed code back to it.
Paolo – One strength of Chicago Boss consists in my opinion in the good amount and quality of its documentation. Would you like to address your favourite online resources to a developer willing to learn more about Chicago Boss? Is there any “real” book about Chicago Boss?
Evan - As much as I love killing trees, there’s no book yet! The closest thing to it is a PDF tutorial on the website, and people are always adding new code samples to the Wiki hosted on GitHub. The best way to get started is to work through the tutorial, peruse the API documents, and hop on the mailing list. It’s an active, friendly place where we welcome in newcomers all the time.
