David's Computer Stuff Journal

Erlang

Posted by David N. Welton Sat, 22 Sep 2007 09:20:00 GMT

As someone who tries to read a lot about my field, I feel I have my "ear to the ground", so to speak. And right now, I'm picking up a lot of hype-rumblings about the Erlang programming language. I have a little bit of experience with it, having used it briefly about 3 years, and having made a few minor contributions.

Why are people interested in it? Picking up new programming languages is fun for some people, but in general, unless it's something backed by millions of dollars of marketing and development (Java, C#/.Net) there needs to be a 'killer feature' to drive adoption. Tk and Tcl, ease of developing simple dynamic web content with PHP, Rails and Ruby, and so on. Erlang, in many people's eyes:

1. gets concurrency right, or at least is a big improvement over existing models (threads).

2. Makes distributed computing easier and does it naturally.

3. Is a solid base on which to construct reliable applications.

That appears to be enough to have nudged Erlang into a position where it has a chance at the big time.

While I would highly encourage people to learn a bit of Erlang, and to seriously consider its use for the type of systems for which it was created, I have some doubts about it becoming that widespread. Please read the following as the thoughts of a critical mind, and keep in mind that it's far easier to zero in on defects than it is to create something from scratch, so do not misconstrue my writing as being "against" Erlang (I do use it, enjoy it, and recommend learning it!), but as an honest appraisal colored by my own view of the world, which might not be like yours.

To begin with the superficial, its syntax is a bit odd. For a professional programmer, that shouldn't present much of an obstacle, and indeed isn't after a few days of using it, but there are a few things that I do find a bit annoying despite being used to the syntax, first and foremost being the use of . and , to separate lines of code, rather than a newline, or ; (which is used elsewhere). They're like little mouse droppings - hard to spot, and they get in your way when you swap out bits of code here and there. The last line of a function must end with a ., but other lines are separated with commas, so when you're cutting and pasting lines from here to there, you end up having to recheck the line endings each time.

Erlang is a functional programming language. Once again, someone with a wide exposure to many programming styles will not find this difficult after a week or so of practice, to wrap your mind around a different way of thinking. However, I have some doubts as to whether a functional language will be able to bring on board the numbers necessary to be widely adopted (see Scaling Down).

One of the benefits of wider adoption is, indeed, having a wider set of libraries - it's a "positive network externality" in terms of economics. Other people have written about the relative lack of Erlang libraries to do various things, but it's actually not one of the things I'm worried about - it's something that will take care of itself if the language grows in popularity. After being spoiled by Ruby's gems, what I really miss, though, is a nice, simple, easy distribution mechanism.

Related to making it easier for J Q Programmer to adopt, the error messages are at times not the most helpful I've seen in the computing industry:

Error in process <0.29.0> with exit value:
{undef,[{shell_default,sfdsf,[]},{erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]}

In English, that means that I tried to execute the function sfdsf(), which doesn't exist. It seems that there ought to be a way to keep the nice, computer parseable error messages, and add in something that humans would find just a bit easier.

Other people have already covered the problems with Erlang's strings, so I won't belabor the point. Suffice it to say that, in my opinion, is_list([foo, bar, baz]) and is_list("hello") should probably not both be true.

Which brings us to another issue. Erlang is a language used in big, reliable systems like telephony switches. That's not the sort of environment where you want to break things, so I doubt that Erlang will ever see big changes that introduce incompatibilities, like Python has recently done. This one is a tradeoff - stable, reliable and backwards compatible is simply not compatible with rapid development of the language - it's a zero-sum game, you want more of one, you get less of the other.

Related, is the "open sourceness" of the language. It is open source, which for me is very nearly a prerequisite for dedicating my time to a language, but Ericsson appears to maintain firm control over it. This is another thing that's both good and bad. Having the backing of a large corporation means that developers are paid to work on and enhance Erlang, which is beneficial to everyone. On the other hand, as some people say, open source is just the start, open development is important too. Random thought: I bet Erlang would make a nice Apache project, but I'm sure the bureaucracy involved would be a nightmare.

In terms of the language itself, beyond the syntax, it feels a little bit too verbose. Perhaps not as much as Java (that would be difficult, wouldn't it)... maybe I'm just used to Ruby, which is about as concise as I'm comfortable with while still being readable. Sometimes, though, there is a little bit more 'repeat yourself' than I would like to see. For instance, in this implementation of string_join (something else that ought to be in the standard library, but still isn't), it's necessary to create the same function, with different arity, simply to work around the fact that it's not possible to say the default separator should be " ":

string_join(Items) ->
    string_join(Items, " ").
string_join(Items, Sep) ->
    lists:flatten(lists:reverse(string_join1(Items, Sep, []))).

Which is a lot more typing than string_join(Items, Sep=" "). This is pure opinion, and very subjective, but Erlang to me feels like it falls more in the "systems programming language" category than "scripting language". It's a bit more verbose, it needs to be compiled to run it, modules need to have an entry point... it's not as suitable to quick throwaways as Ruby, Tcl or Python. Of course, it is certainly higher level than C, and leaner than Java, but still falls an the other side of an admittedly fuzzy line in my head. Its command line options reinforce that. Whereas "scripting" languages do the obvious thing first:

ruby foo/bar.rb

Erlang is a little bit more complex:

erl -noshell -pa foo/ -run bar

A minor detail, once you get used to it, but still, I prefer the "do the obvious thing first, and let the user have some say in the matter if they want to do something else" approach to systems design.

One of the wonderful things about Ruby on Rails, is that it uses Ruby throughout, templates included. Without getting into the merits of using templates vs other systems, my own opinion is that Rails gets them right, and demonstrates the flexibility of Ruby by using it as the language for the templates, rather than inventing some other solution. I don't see the same flexibility in Erlang, which is unfortunate, as it blows Ruby out of the water in terms of being a very solid solution to deploy on a server (no fiddling with proxies and load balancers and single threaded mini-servers + hot code replacement = nice).

Of course, there are lots of good things about Erlang, as mentioned at the beginning of this article - concurrency and distribution, but also language features like pattern matching that are a lot of fun to use, a pleasant syntax for dealing with binary data, list comprehensions, first class functions, tail recursion, and lots of other goodies. However, if I had to try and predict the future, I could easily imagine another language grabbing some of Erlang's good ideas and running with them, perhaps being more "conventional" in other respects - this isn't uncommon in the languages field, as we've seen with things like Lisp and Smalltalk. On the other hand, one of the reasons I *am* quite happy with Erlang is that it is most certainly not a proof of concept - it is a very practical language that excels at solving certain classes of problem, and does so in many commercial settings. If you're the kind of person who enjoys new things, check it out!