Exploring Erlang

When I first began running hydrodynamic simulations in graduate school to model astrophysical gas flows, I was curious why we were using that antique programming language Fortran, rather than something slick and modern like C. I had learned Pascal as an undergrad, and knew that there were many programming languages, each with its own strengths and weaknesses. I was frustrated with how crufty the Fortran code felt, but was assured by my professors that Fortran was really the best language for the job. Of course in retrospect, that the code was unmaintainable and difficult to extend had much less to do with the language, and much more to do with the lack of skills by it's implementors. These programs got the job done, but were hardly things of beauty to look upon with pride.

More recently at a startup, I first became aware of the concept of a supervisor program, which starts a worker program, and automatically restarts it if it crashes. This wonderful piece of engineering was a godsend, and allowed me to sleep through the night when I was on pager duty. Any time one of the app servers crashed, it was immediately restarted by the supervisor. Alas, the miracles of supervision didn't extend to restarting MySQL master-master replication when it failed — which it often did — so I still had to occasionally get up to manually fix problems that could not be automated away.

But the idea that software could be made more reliable sunk in. And while I loved programming in Python at the time, I began to look around for languages better aligned with my newfound philosophy that software should be able to heal itself when it fails.

It doesn't take much time googling "fault tolerant software" to run across Erlang. For someone like me who was steeped in Algol based languages, the syntax seemed painful. So, I dismissed it, and kept looking. Still, the more I researched, the more Erlang kept popping up. And once I dug a little deeper, reading more about the language, it seemed like something definitely worth exploring. When I discovered that Supervisors are a first class Erlang "behaviour", I was hooked.

I am currently working on my first real Erlang program, called subdomain. It allows a user to create email addresses for his or her personal subdomain, which relays email to some real mailbox. I have used this technique for years with my own domains to create email aliases for each entity I encounter that wants my address. For example, if my subdomain is jay.m82.com, and I encounter some web form at http://example.com that wants my email address, I would create the alias example.com@jay.m82.com and enter that in the form. Mail sent to that address will be relayed to wherever I've configured it, a gmail account in my case.

While this application may not be the poster child for Erlang's concurrency and fault tolerance capabilities, it is an itch I've been wanting to scratch for a while, and it's a step toward a more robust programming future that I'm greatly looking forward to.