Popularizing Erlang

I’m definitely more of a backend systems guy than a UI designer. This might explain why I’m still using a Dell laptop running Linux rather than a shiny, sleek Apple MacBook like most of my friends. My interests tend to run towards networks, distributed applications, and databases. I’d rather spend my time reading about, say Plan9 or CouchDB than the latest Ajax tookit or CSS hack.

So, Erlang is just about the best language for me. It offers most of the features I need to write scalable, distributed applications. The _only_ thing I’d like to change about it is string handling. The fact that Erlang represents strings as byte arrays gives me the heebies. It’s not caused me any problems with the bit of hacking I’ve done so far, but it somehow just feels wrong. A little voice in the back of my head keeps saying “byte-based strings are gonna hurt someday”.

Back to my main point. I read this post and my first reaction to it is that it’s a nice idea motivated by a sincere desire to move Erlang forward. I have a tremendous amount of respect for programmers willing to throw wild ideas out to the world. As a learning exercise, I think Erlectricity is a fine idea. But I think this is exactly the wrong approach to popularize Erlang for a couple of reasons.

First off, the only real way to get more developers using Erlang is to get more developers writing Erlang. Using Ruby for all the heavy lifting and Erlang for just bits n’ bobs relegates Erlang to the “backend systems” ghetto and erects obstacles to finding truly innovative ways to use Erlang. Imagine if, before Ruby was a hit, a JNI bridge between Ruby and Java became popular. Java has a lot of libraries, arguably more than Ruby, even today. The argument could’ve been made that leveraging all those Java libraries made good sense. How would that have impacted Ruby library development? Would we have had more Ruby->Java wrappers than native Ruby libs? I think so. The point is programmers need to use and get comfortable with whatever language their trying to adopt, in this case Erlang. Otherwise, you get Ruby developers hacking, in the pejorative sense, Erlang instead of Erlang developers hacking, in the good sense,  in Erlang.

Second, there is a severe performance and scaling mismatch between Ruby and Erlang. It’s common knowledge that Ruby is slow. It’s slow for a number of reasons including a lack of native threading and a global interpreter lock allowing only one Ruby thread to execute at a time. Erlang lives and breathes for highly concurrent environments, like web applications. See Joe Armstrong’s post for an example on how well Erlang scales. I just can’t see how to interface the two languages that doesn’t result in a major performance bottleneck. At the very least you’ve got marshalling overhead between the two. And when the performance differences are factored in along with the single-threaded nature of Rails (the worlds most popular Ruby framework) it gets really gnarly.

My idea for popularizing Erlang is simple: write the code needed to make Erlang more commonly accepted. I’m not sure what that code needs to be, though I’ve got a few ideas. But I am sure that it’ll be written in Erlang .