After learning 15 or so programming languages, in different levels of proficiency, I don’t tend to get excited about a new programming language. Moshe occasionally sends me links to the project websites of new languages. I usually reply that “If you know you’re OOP, you don’t need 5 extra levels of fluff just to get things done”. One of his links, however, hit the bullseye: Erlang.
Erlang stands out in the landscape of new programming languages: It’s a pure functional language. Yes, you’ve read it right: Pure. No pointers, no shared memory, no side-effects. If you want something stateful in Erlang, you have to use special libraries.
Erlang, however, is not an academic language. That radical design derives from very practical reasons. Erlang was designed for a single purpose: To support concurrent, distributed, fault-tolerant systems. Anything else in Erlang derives from this goal. Since that many bugs in distributed systems are caused by shared resources and other mainstream-languages imperative features, the designers of Erlang simply threw them out. You can’t code a casting error in ML, and you can’t code a race condition in Erlang.
(To be honest, you actually can – The language is not that sterile. However, the combination of well-selected language features and supporting, optimised libraries makes it less frequent.)
The weapon-of-choice in Erlang are processes. Most PLs discourage massive multi-processing, or even multi-threading. In Erlang, there’s little point in writing a single-process application. Processes are the thing that work in Erlang. They can have a state, open communication channels, receive and send messages and so on. In many ways, processes in Erlang are what objects are in OOP languages.
You can learn a lot about a programming language from its standard libraries. C have glibc, with it’s drill-down-to-hardware system calls. C++ have STL. Java have – Well, there are gigabytes of available Java libraries out there, but most of them are based on in-memory objects and data structures. Erlang’s stdlib includes generic servers and processors pools. To finish Erlang’s “Getting started” tutorial, you need more than one computer.
I could go on more and more about how Erlang, IMHO, is an enterprise applications framework that finally makes some sense, but admittedly, I’m not yet skilled enought in it to give it praise. I’ll just say that for the first time in a few years, I’m making the time to study a new programming language.
(Btw: “Erlang” menas “Ericson’s Language”, after the Swedish telecom company that initiated it. Maybe, after many years of cursing Bjarne Stroustrup, we can forgive the people of the north.)
Yep, Erlang is very cool, and there’s a very good book by Joe Armstrong himself (http://www.pragprog.com/titles/jaerlang/programming-erlang). As for language name, it is deliberately ambiguous (http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf).
Erlang is not a pure functional language. It has lots of ways to have side effects. Message passing itself is a side-effect that even has its own operator. Updating the process dictionary is another way to have side-effects.
And Erlang _also_ gets its name from Agner Krarup Erlang that invented some statistical distributions that are good for dimensioning telecom systems.
I know that Erlang is not entirely pure-functional, but as you mentioned, you need a process in order to maintain state. The fact that statefulness is a process feature and not a data feature (as in OOP) shows the process-oriented approach of the language.