Bob Ippolito on Erlang

April 14th, 2008  |  Published in commentary, conferences, erlang, review  |  8 Comments  |  Bookmark on

I finally got around to watching and listening to Bob Ippolito‘s “Exploring Erlang” video, and I don’t know of any more thorough hour-long introduction to the language than this one. If you’re interested in Erlang but are too busy or too lazy to read Joe Armstrong’s great book or any of the many papers and articles that describe Erlang, then Bob’s talk is for you.

A few interesting points for me:

  • In a few places Bob mentions that while he finds Erlang syntax unusual it’s really no big deal, and you quickly get used to it. I can verify that he’s absolutely right. A lot of people seem to get really hung up on this issue; if you’re one of them, all I can say is that your concerns are very greatly exaggerated.
  • Along the lines of the previous point, one of the questions Bob takes after his presentation is from a gentleman who says that his technical lead refuses to use Erlang — in a telephony application, no less — and that his tech lead rolled his own stuff for concurrency and interprocess communication. Hmm, I wonder if that technical leader’s initials are “N.I.H.” It would be interesting to see how well his solution could hold up in the environments in which Erlang has already well proven itself. Given all the attempts I’ve seen over my career at solving such things, many of them made by people who mistakenly think it’s not that difficult to get right, my guess is “not that well.”
  • Bob mentioned that he finds Erlang to be a very small and thus easily learnable language. He’s absolutely right about that, too; I wish I could count the number of times I’ve said the exact same thing in conversation, in presentations, and in writing. Many people who come from Java or C++ or other general-purpose languages assume that languages need to be huge to be useful, so they assume that small languages must be toys, and they also assume any “real” language requires years to learn. How incredibly wrong they are.
  • Bob keeps the whole discussion grounded by explaining how Erlang saves him and his team time and money. In case it’s not clear, he’s talking about actual time and actual money. He explains that he can serve millions of web requests per day from just a single machine (though he naturally uses more than one for redundancy and reliability), for example, and by mentioning the small size of his team — I think he said 8? — he hints at the productivity that Erlang affords. My experiences are, again, quite similar.

Coincidentally I also watched Jim Weirich‘s “Shaving with Occam” presentation from the MountainWest RubyConf 2008 held at the end of March, and was pleasantly surprised to find that he devoted a good portion of his talk to Erlang. He mentioned how it was like Lisp in the sense that it has a small core, simple rules for manipulating that core, and powerful abstractions for building new things from the simple rules and small core. Yet, I shouldn’t be surprised. I don’t know Jim at all, but judging from the dates he mentions in his talk I think his career spans around 30 years. It’s also pretty clear that he’s had broad and deep experience with many technologies during that time. From what I’ve seen, people like Jim who have an incredibly deep first-hand understanding of the utility and importance of simplicity, brevity, and powerful abstractions in software development seem to have no problem whatsoever quickly seeing and comprehending the immense value of Erlang.

You’re still not exploring Erlang? What are you waiting for?


  1. markus says:

    April 14th, 2008 at 5:58 am (#)

    Well to be honest I can understand people that are concerned about the syntax. It may be superficial but on the other hand one needs to know why to use a language that has a syntax which is not appealing.

    The thing is, from this point of view, it is easier to sit around and use ruby or python, and try to “steal” good ideas of other languages, rather than diving in and writing many thousand lines of code (which you need to maintain afterwards too, unless it is just practise)

    The only idea I seem to have understood with Erlang is that it is a language that is fault tolerant (insofar that individual components “may” fail as long as the overall result will be achieved)

  2. Cedric says:

    April 14th, 2008 at 1:11 pm (#)

    The syntax is only one small part of the picture describing why people are reluctant jumping on Erlang. I think the absence of any OO concept (and Joe’s obvious bias against OOP in general) is making code reuse in Erlang very problematic.

    This is even visible in his book (which I thoroughly enjoyed reading) where a lot of the listings are basically the same source code shown a few pages before but with one or two lines modified.

  3. steve says:

    April 14th, 2008 at 6:15 pm (#)

    markus: what is “appealing” syntax? Does that refer only to syntax that’s just like the syntax of whatever your favorite programming language might be?

    Erlang syntax is quite simple. Like Bob says in the video, it takes about a single day to get used to. I’ve been programming in both Perl and C++ for exactly 20 years now, for example, and I can confidently say that Erlang is much easier syntax-wise than either of them. But frankly neither of them bother me much as far as syntax goes, either.

  4. steve says:

    April 14th, 2008 at 6:32 pm (#)

    Cedric: reuse does not require OO. I get quite a bit of reuse out of Erlang, and I get reuse out of emacs-lisp too. When I used to use C I got a fair bit of reuse out of it too, and many still do. What about reuse in Perl and Python? Check. Reuse comes from properly expressing abstractions with the appropriate facilities provided by the language at hand.

    Have you ever written a book? I have. One thing you have to do when writing a book is make the examples relatively self-contained, otherwise the readers send you unfriendly emails and write unfriendly reviews for making them page around to find the parts of the code you “reused” and thus left out of the example they happen to be staring at. The moral of the story is that you shouldn’t judge whether Erlang allows for reusability only by looking at examples in a book.

  5. Cedric says:

    April 15th, 2008 at 11:56 am (#)

    Hi Steve,

    Yes, I wrote a book as well (“Next Generation Testing in Java”). Your point is well taken regarding the need to show self-contained examples to your readers.

    I still stand by my claim that Erlang makes reuse difficult in general, but it’s more due to pattern matching than Erlang per se. The problem with pattern matching is that it’s basically a glorified switch/case, and there is no easy way to reuse existing ones (another problem with pattern matching is that it completely breaks encapsulation, but that’s a separate topic).

    I agree that Erlang’s syntax is easier than Perl and C++, but that’s setting the bar a bit low, don’t you think? :-) Personally, I found Erlang’s terminators quite confusing, but that’s fine, I can deal with esoteric syntaxes if it’s worth it. I just don’t think Erlang is.

    I took a deep dive into Erlang some time ago, and here are my impressions:

    In a nutshell: I enjoyed the book and I liked having my traditional conceptions of software engineering challenged, but Erlang suffers from too many deficiencies (detailed in my posts) to stand a chance of becoming mainstream any time soon. I was particularly disappointed to realize that the claims about Erlang heling with concurrent programming extremely exaggerated.

  6. steve says:

    April 15th, 2008 at 7:38 pm (#)

    Cedric: how much production Erlang code have you written? I’ve written quite a lot and I simply don’t see the issues you claim are there.

    I remember reading those blog entries you cite in your comment above, and I remember strongly disagreeing with them. The opinions you state there simply don’t strike me as having been born of real in-depth experience with the language.

    For example, if you didn’t find that Erlang was head-and-shoulders above almost all other languages when it comes to concurrency, then I really do fear that you somehow got yourself onto a very wrong track. Erlang’s concurrency support is easily and clearly superior to anything I’ve seen before, and trust me, I’ve been developing concurrent systems for a very long time.

    At the end of the day, if you don’t want to use Erlang, then that’s your choice. It doesn’t affect me one way or another, as I fully intend to continue to take full advantage of it.

  7. Ulf Wiger says:

    April 19th, 2008 at 12:55 pm (#)

    The claim that Erlang makes reuse hard comes up here and there in the blogosphere, but I don’t recall hearing it from someone who’s actually written serious code in Erlang.

    I would claim the opposite, based on my experience from large software projects using Erlang during the past 12 years. Not only do I find reuse quite easy in Erlang – I believe that we practically always achieve a much higher degree of reuse than similar projects in C++ or Java. We have also found that it is fairly easy to rewrite parts – even fairly large parts – without jeopardizing quality or performance. This is vitally important in long-running projects, and when building lots of different products on the same software base.

    Things that greatly simplify reuse in Erlang are polymorphism and pattern-matching, of course, as well as the black-box style programming, but also the fact that it has a pretty clear idea of how software should be written. OTP takes this further and provides ‘behaviours’ and libraries and a consistent notion of architecture and programming style.

    My impression of reuse in C++ is that, while it is quite possible to achieve a high degree of reuse in you own code, reusing code from other projects is much more problematic.

  8. Weekly SOA crumbs #15: Have you seen the latest “mesh”up from Microsoft? - Service Endpoint says:

    April 29th, 2008 at 9:52 pm (#)

    […] interesting links Bob Ippolito on Erlang Dino Chiesa on Varying Content-Type according to the URL in a WCF REST […]