By Cameron Laird and Kathryn Soraiz

Welcome! This is Regular Expressions, or, more precisely, its early-September 2008 installment. Regular Expressions is a column we've written around a hundred times already, stretching back to the late '90s. We're excited to bring it now to Linux Developer Network (LDN), which will publish two installments each month.

LDN focuses in September 2008 on different aspects of kernel development and management. We'll be back mid-month with our own slant on kernel work; first, though, we return from the US Labor Day holiday this week wondering why everyone doesn't use Erlang? Regular Expressions' usual domain is high-productivity languages like Perl, Tcl, and Python, and specific news or ideas that help make the most of them.

Serious Tool

Erlang certainly belongs in the category, and we've written about it several times before. Erlang is, among other things, a serious language: its best-known applications are in big mission-critical telecommunications systems, the German national air-traffic control organization, and Facebook's chat. When first prototyped in 1987 (roughly the same era Perl, Tcl, Python, Sather, and others emerged), Erlang already emphasized concurrency, scalability, and reliability.

With hardware vendors promoting multicore processing, and "scalability" firmly entrenched in the vocabulary of even executives, why hasn't Erlang taken over the world? It's quite a nice language, and has struck us for several years as having real potential for turning into The Next Big Thing. There also are reasons it hasn't happened yet, though:

• Nobody hires Erlang programmers;
• There are no Erlang programmers to hire, or from whom to learn, or with whom to chat;
• There are no Erlang books;
• Erlang looks funny;
• Erlang string-handling is painful;
• Erlang has abundant syntactic blemishes;
• Erlang isn't object-oriented;
• Erlang debugging is different;
• Erlang has no security model;
• The Windows version of Erlang had problems;
• Database interfaces have been primitive; and
• It's hard to make graphical user interfaces, to deploy applications, or often even to communicate on the command-line when writing Erlang programs.

Note that what holds Erlang back is that people believe these things, a distinct matter from their truth. Let's look at both the beliefs and the truths.

Erlang Culture

There's no question that, in comparison with Java and C#, Erlang is a minority language; in fact, while recruiters are able to pronounce "Python" and "Ruby" now, "Erlang" remains alien to them. As near as we can tell, there are only a few jobs world-wide that open each year for Erlang adepts.

On the other hand, it's at least pleasant to be able to talk about programming a Web server with an order-of-magnitude more capacity than Apache, and that's an advantage Erlang students have. While you're unlikely ever to be hired as an Erlang programmer, you might well be hired as a programmer who demonstrated your value through your Erlang programming.

There are far fewer classes or fellow programmers or on-line forums focused on Erlang than on Perl and Fortran, say; still, by our estimation, there's an adequate "critical mass" to make for a healthy community. Not only does the Erlang User Conference 2008 in November look to be of its usually high quality, but Erlang gets enough attention to support a session at OSCON 2008 and other general-purpose conferences, the First International Erlang Exchange, and a variety of local meetings. While you're unlikely to find a class in Erlang at your local community college, don't be surprised if a question you post on-line is answered by one of the top Erlang experts world-wide.

For a long time, it was effectively true that "there are no Erlang books". Programming Erlang (PE) single-handedly changes the terms of that debate, though. Published last year and available both on paper and as PDF, PE is a milestone for the language and concurrent programming more generally. Author Joe Armstrong was a co-creator of Erlang, and he's taken good advantage of the intervening decades to present Erlang as a fully-modern, if unusual, language. Thinking in Erlang is a Creative Commons-licensed introduction for experienced programmers, the reference on-line documentation has become easier to use in recent years, and O'Reilly has its own Erlang Programming scheduled to appear on bookshelves early this winter. PE has gaps--it is unpersuasive, for example, on the advantages of functional programming--it certainly handles its chosen topics with mastery. If you step through PE diligently, you'll be at least an accomplished intermediate Erlang programmer.

Serious Annoyances

Enough of what it's like to work in Erlang; how does actual working Erlang code look?

If it's doing a lot of string-handling, it might not be pretty. Erlang doesn't privilege a native "string" class", but provides facilities to interpret lists of integers as display codes. List handling--including list comprehension, functional composition, and parallelized evaluation--is sophisticated.

The standard library just doesn't go far, though. One of our first needs with any language is convenience in processing Unicode. Erlang's strings make for a viable foundation for Unicode transformations; this is not PHP, where all releases before V5 were fundamentally broken in their Unicode capabilities. Erlang mostly leaves the coding to us, though: a need as common as a UTF-8 to UTF-32 translator looks this messy.

Reversal of a string, either word-by-word, or character-by-character, is far easier on the eyes. Erlang builds in several of the functions that are less academic but far more common in real code, like string:strip(), for trimming whitespace. Erlang also has more capabilities to use regular expressions than most programmers will need, including at least partial internationalization.

More broadly, however, Erlang doesn't look like C and Java. Its clearest syntactic ancestor is Prolog. Damien Katz makes several points about Prolog's syntax that reinforce that, while Erlang is expressive and precise, it's also ill-suited to the world of line editors, syntactic abbreviations, and enterprise-sized user interfaces. As he points out, Erlang effectively doesn't allow

	if
	Logging ->
	  log("Something happend")
        end
    

but requires

	if
	Logging ->
	  log("Something happend")
        true -> ok
        end
    

Erlang also has several syntactic restrictions that are hard to understand. We're not just speaking about trivially arbitrary choices, like the requirement that names of variables be capitalized; Andrew Cooke highlights such puzzles as compose_1. Erlang is nominally a functional language--but the syntax for function composition takes a detour through the run-time library! As Cooke summarizes: "... Erlang punishes you when you write code in a functional style."

Not OO

Erlang isn't object-oriented. It's functional, or nearly so, depending on how pedantic you are about side-effects. Occasionally someone argues that Erlang is OO, if you squint enough; people who do that are just mistaken. People on the opposite side think that Erlang's functional orientation just is inadequate, because object orientation is necessary in contemporary programming. Those people are also wrong.

For a couple of years, Erlang behaved unreliably under Windows when attempting to listen on a network socket. This serious problem was eventually localized to an apparent error in the Winsock API, and has been corrected.

Erlang doesn't manage "sandboxes" or other security models to isolate untrusted code. That's a difference from Java, certainly; it's still not clear that this is truly a handicap for Erlang.

Debugging and development more generally are different in Erlang than in the Eclipse-Visual Studio mainstream. One of Erlang's great strengths, of course, is its robust concurrency model. Erlang's message-passing is different--a lot different--from programming with threads. While this is a net positive for coding with Erlang, it involves change. Development with Erlang is more like working in Smalltalk or Tcl or Forth than in Java or C++. If Java programmers spend their time in sophisticated debuggers poking through the traces different threads have left on the stack, Erlang programmers rely on introspection and interaction to reason through the events that have happened.

Erlang is also like Smalltalke and a few other languages in its insularity; coding in Erlang is so wonderful and productive that it took a long time to get around to mundane chores like interfacing to common database management systems. Erlang's foreign-function interface (FFI) is hard to use, so it's essentially infeasible for anyone except experts to bind to common C-coded libraries. In the same vein, it can be a considerable chore packaging Erlang code and configuration so that what works on our machines works equally well on yours.

That's about it. If your focus is on fixing up a shopping cart for a Web site that has to go live today, there's plenty of reason to ignore Erlang: it looks funny, takes a bit of adjustment, and doesn't do easily much of what programmers do most days. However, if you have an interest in highly-reliable, highly-scalable software, software "pre-adapted" to the massively multicore and often distributed hardware that seems to be in our near future, it's a great time to learn Erlang.