Erlang Style

Joe Armstrong's Programming Erlang book was featured at the Pragmatic Bookshelf booth at OSCON last week. The banner covering the back of the booth was simply the cover of the book itself. They said the book has been selling very well.

I hosted a BOF on Monday evening. The slot was assigned, and not the best, I thought, since that was the first tutorial night. As it turned out about 20 people showed up, so I wonder how many may have been there on a Tuesday or even better, a Wednesday.

A handful of the attendees had tried Erlang to some extent. Everyone had an inkling of what it is about, and wanted to find out more. So we turned the hour into a quick tour of what I consider the features people should see first if they're coming from the more common languages at OSCON (i.e. the "scripting" languages, Java, C++, C).

I had Emacs up on the screen with "erl", the Erlang expression evaluator, and a few interesting source files. I also had Firefox with some tabs browsing the extensive Erlang/OTP documentation. Here's how it went down:

Roughly 30 minutes on the sequential aspects of Erlang. Really just a few essentials:

• Some data types: numbers, symbols, strings, lists, and tuples. (Distinguishing the last two had a bump -- I'd not really thought about explaining that!) I did not bother to explain records. Although they're simple in Erlang, they do need a good bit more explanation. (I'd hoped to avoid the point that strings are just lists of characters, but that came up in a question. And I certainly did not mention "binaries".)
• Variables begin with a capital letter (latin1) and are "single assignment". (That took a few minutes to demo and respond to clarifying questions.)
• Variables are bound through pattern matching. A simple assignment statement is actually just the simplest form of binding through pattern matching. (Code some examples into the evaluator. Then I made a mistake: I demo'd the evaluator's f() command to forget one or all current bindings -- this has nothing to do with Erlang and so I had to unwind a bit.)
• Functions are defined by one or more clauses, and pattern matching is used to select a clause when the function is applied to arguments.
• Recursion (and tail recursion), as there are no mutable variables and so no "loops" per se.

That was it, and my 30 minutes for sequential Erlang were up. I made it clear there's a lot more to sequential Erlang than that. The timing worked out pretty well though. I had not intended on explaining more about sequential Erlang. This was enough to read my code for concurrent Erlang.

The last half of the hour was spent on concurrent processes, message sending, and message receiving (again, via pattern matching clauses). No supervisors, no linking, no nothing but the simplest examples of spawn, send, and receive.

The first concurrent example was an rpc because people know it, and programming it in Erlang is trivial, *but* coding it in Erlang highlights that it *has* to be coded. Erlang messages are asynchronous, fire-and-forget, and the code for rpc makes that explicit.

Finally I demo'd loading updated code into a running process. This is easy to show and I thought people using languages that do not define such a thing or that define such a thing using horribly complex mechanisms would be impressed. Seemed so.

Given the response to the BOF, I suggested on the Erlang list that someone should provide a half-day tutorial next year.