Erlang is a Specialist Language

We've all heard a lot about the "coming multicore revolution" and about how all us simpleminded programmers better get our stuff together to "program for multicores." This in part is what has given Erlang a certain amount of buzz, and the appearance of the very nice book by Joe Armstrong, Programming Erlang, on the Practical Programmer imprint (the fine fellows who piloted the Ruby boat that O'Reilly missed, thus destroying O'Reilly's cool factor).

(Side note: if you want an excellent book on Erlang, you should pick that up. If you want a terrible book, you should also pick it up. In fact it's pretty much the only book in town, so whether you love it or hate it (I quite like it) it's your only choice. The second edition of Concurrent Programming in Erlang is long out of print and hard to get. The other "recent" book is in French.)

As is well-known, this has led to a fair number of people being attracted to some of Erlang's technology (strict message-passing concurrency, transparent distributed programming, very lightweight processes) and turned off by a "bad" first impression of the language. I'm not going to get into all the things that turn people off (except to say that I don't really mind if they are; as far as I'm concerned, the question isn't whether Erlang is right for you, but whether you're right for Erlang). But I want to address this point:

Erlang is a specialist language, and your task X falls outside of it, so it's not really a fair criticism.

This surprised me--the idea that somehow Erlang fit only a small set of problem domains and was a "domain-specific language" (for, say, telecom applications, I guess) for these areas. And it wasn't a a good "general purpose" language.

This view is sometimes supported by Erlang's biggest boosters:

9 ++++ interface to flash using flex 2. Solve the GUI problem once and
for all as follows

repeat after me: client = flash in the browser, server = erlang.
Intermediate protocol = flash AMF

The "GUI problem" Armstrong refers to here is the fact that Erlang's built-in graphic facility is based on the famously ugly Tk toolkit, and shares some of its limitations. To me this feeds into the idea that Erlang is at most a "server side" language and not the sort of thing you'd want to write a desktop application in.

To all this pigeon-holing, I say hogwash. Erlang is not "domain-specific" and it's a good choice of programming language for all kinds of applications. It's just that Erlang is so good at writing servers that it seems like its role in life.

We accept that Erlang is great for writing systems with the following characteristics:

• "Soft" real-time performance
• High concurrency
• High availability
• Network-oriented

To me, it's the rare application that doesn't have at least one of these as a desirable characteristic. (The meaning of "soft" real-time has been debated before: to me, it means the absence of performance "surprises", not necessarily the idea that everything happens immediately. I've had a lot of these with other languages: Ruby has seemed full of them; Java has its share--every request gets served in 100 ms except for sometimes, when the garbage collector hits and it's 2000).

Who writes any kind of application, even a script, and wants to make sure it performs inconsistently, does operations serially, crashes often and doesn't use any network protocols?

These are really all well-known virtues of the Erlang technology: the Erlang OS, the Erlang/OTP platform, and so forth. In theory they could be had using a entirely different language: look at Lisp-Flavoured Erlang or Termite Scheme.

But I want to apply a little love to the language itself. I don't accept that having a Prolog-derived syntax is a necessary negative. In fact, it makes a great deal of sense it control a program as a series of clause selections by pattern. It's quite "natural"--it's a lot more natural than nested conditional constructs and the kinds of control structures offered by other languages. Arithmetic and function application follows the straightforward algebraic convention. Except for Haskell, Erlang is probably the language that looks the most straightforwardly like math to me.

I don't really know of a common programming task for which I wouldn't prefer to write an Erlang program--in the areas where it shines it's better than just about anything else (except for exotica like array programming languages) and, otherwise, is just as good.

Back to Armstrong's GUI problem. It unfortunately misses the bigger point, and rather badly. The "coming multicore revolution" isn't about programming for multiprocessing on servers. Servers have had multiprocessing for gobbles of time. Every server application is concurrent. Servers have plenty to do even without doing funny things with lightweight processes. Heck, Erlang itself didn't have an SMP-enabled scheduler until just "recently" (in the last couple of years)--and this didn't really limit its ability to take advantage of multiprocessing servers.

The point of "the multicore revolution" is that no processor can just be made faster now--every processing application will require multiprocessing in order for it to scale. The generation of "newly concurrent" applications will be on things like desktop machines, entertainment consoles and small devices; not server applications, where concurrency is old hat (though it's true that essentially all server applications could benefit from Erlang's concurrency model).

In short, saying that Erlang's GUI should live in a web browser is busted: Erlang is (or should be) a great language to write a web browser in. Or a MMORPG client. Or a photo processing program. Erlang models tasks as a set of concurrent processes receiving messages and replying to them--what about that isn't an excellent mapping to the event-based programming of GUIs?