Tim Bray and Erlang

Erlang is getting a lot of attention these days (LtU was there first, of course: we had in depth discussions of Erlang several years ago). One recent discussion is around Tim Bray's experiments with Erlang. Steve Vinoski provides timing results showing the effect of utilizing Erlangs concurrency features on Tim's challenge.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The future?

I wonder, by the way, which new language (or languages) are the Erlang's of the future. Which languages should we be discussing now, to stay ahead of the curve and predict which language will become the focus of attention three years from now?

feature vs language (aimo)

I think Erlang style features (immutable message passing and lightweight processes) can be added to any language as easily as threads, which are almost but not quite orthogonal to other language features.

When does addition of such features make a new language? In theory, any language might become the Erlang of the future when used suitably. Is the change larger than adding oo or strong types to a language? Or smaller?

(Let's use the phrase "nature vs nurture" or n-vs-n to describe the conundrum of whether a language makes it easy to do something or not based on "DNA" alone, rather than needing something bolted on. Every Turing complete language can do anything by nurture — only some do so easily by nature. Please take all my comments modulo the n-vs-n meme so we don't make another n-vs-n thread.)

In essence, I think it's useful to discuss the semantic effect desired in Erlang independently of the language. We just haven't a coined buzzword for it yet, like oo or types. Aren't the key words async, immutable, and message? That would spell aim, with the disadvantage it's an English word. (Ambiguity doesn't help terms.) You could call Erlang's style aim-oriented, or xyz-oriented for some other combination of good acronym letters.


Don't the Erlang guys call it Concurrency-Oriented-Programming?

Buzzword attempt

Lightweight Message Passing (LMP), (LWMP), which has the nice property that it's hard to tack oriented on to it :) Doesn't really emphasize the lightweight processes part, which is unfortunate.

I would say that it should apply to CSP-like languages like occam and Limbo (I guess that's up for debate). Anyway, here are some test cases:

Limbo, occam and Erlang are LMP languages.
Termite is an LMP system based on Gambit scheme.
LmpLib is an LMP library for superlang.

Looks alright, doesn't seem like a sellable acronym though.

Not necessarily

I think Erlang style features (immutable message passing and lightweight processes) can be added to any language as easily as threads

Not any language. Erlang-style concurrency requires processes to be isolated from each others' variables; that would be hard to add to C. It could be done, but it'd be more work than threads.

easy as threads

John Stracke: Erlang-style concurrency requires processes to be isolated from each others' variables; that would be hard to add to C.

I know. One must often simplify a lot to reduce comment size by a 1000 to one factor to fit in contexts like this. So in my post, by "easy" I meant something like "on the general order of difficulty as". And it's tempting to turn the word "process" into a long exegesis so you might allow my next remark, but I won't.

It could be done, but it'd be more work than threads.

Depends. Suppose C never had threads before, and your goal was to end up with both the pthreads API and implementation on all major platforms. And suppose you had to write the docs for pthreads, and bring folks up to speed. All that would be included in the cost of "adding threads to C" if you weren't able to ride on history.

I'd say that was at least as expensive as what you'd have to do in order to present a partial (as pthreads is partial) implementation of consistent Erlang-ish immutable message passing in lightweight "processes" in C. So I don't know why you bothered to disagree.

Now, if I was going to add Erlang style concurrency to another language, I'd actually be implementing it in C (or C++), giving me a "partial implementation" for the language in question only. I expect this will be easier than adding (say) pthreads to C from scratch. So I'd argue in the opposite direction you did. Split the difference? [cf]

My crystal ball says...

...the PLs with the biggest upside (at the moment) are Scala and F#. Both try to leverage VMs that are in widespread use and play nice with code written in more widely used languages.

(History hasn't been kind to languages that might be unkindly classified as parasites, but I'm guessing that is bound to change at some point).

I suspect your crystal ball is blind

Chris, the crystal ball never talks about qualities of PLs but always about brands. Java is the language for enterprise applications. C++ is for systems programming. Ruby is the language for Web 2.0. Erlang does concurrency right. JavaScript is for the web browser. Python glues and binds everything etc. These are brands, not "a good multiparadigm programming language for the CLR or JVM". In our beloved IT trash world of hope, hype and hystery this doesn't make a difference. An "academic" language is one where people take a look and say "oh, interesting" and move on.

Crystal balls are mystical, defying explanation...

Chris, the crystal ball never talks about qualities of PLs but always about brands.

I personally think that branding is a something that occurs ex-post-facto. The reasons why languages gain traction is more complicated than mere slogans. The branding is what happens after a PL gains a significant foothold and seeks a massive market presence. As much a defensive maneuver seeking to further entrench a language. As always, history belongs to the winners - and it is not always an accurate reflection - much less a divining rod for the future.

Java is the language for enterprise applications.

Java became popular because of the quality that it could run in the browser. After it gained widespread attention, it was repurposed by Sun and IBM for the Enterprise - mostly in an effort to keep MS from taking over the world.

C++ is for systems programming.

C is the language for systems programming. C++ is a better C, with the qualities of classes - later repurposed to the qualities of generic programming with templates.

Ruby is the language for Web 2.0.

Ruby is the language of Rails, which is only vaguely related to the blob of features that is attempting to be marketed as web 2.0.

Erlang does concurrency right.

Concurrency is a quality, not a brand per se.

JavaScript is for the web browser.

Along with Rails, I'd agree that languages which attach themselves to an environment that becomes ubiquitous will become important players. Yet, that just makes the question of prediction become even harder - now you must not only conjecture about the language, you also have to guess about what application will carry it along. And in those situations, the language is very much not a primary concern.

Python glues and binds everything etc.

Also a quality. But I'd prefer to say that Python is a better Perl. :-)

In our beloved IT trash world of hope, hype and hystery this doesn't make a difference.

IT is reactive in terms of programming languages. If it was up to IT, we'd still be using Fortran and Cobol - they are not really keen on change.

Anyhow, I think Scala and F# are the two languages that stand the best chance of becoming relevant on a larger scale (though I just rattled off the fact that their barrier to entry is smaller given their use of existing VMs). The reasons they will gain traction is listed in a number of other places. I don't think that either will become the next Java or C++. But the question was in relation to Erlang - which by market share is still dwarfed by mainstream languages including Python, Ruby, and Perl, which in turn are dwarfed by C, Java, etc...

The obvious answer...

What languages are we discussing now?

Well, we do discuss Scala

Well, we do discuss Scala and Oz quite a bit...

Part of the reason I asked my original question was that I am not sure LtU is as inviting to new members as it once was, and new views often come from new people with new ideas.

If it wasn't for Luke who educated us about Erlang, I am not sure we would have realizdd just how cool it was that early on.


Perhaps ML5 ?

I think the concatenative

I think the concatenative languages (Factor, Joy, Cat) are a whole lot more expressive than most of the languages being discussed. Or maybe it's time that true data flow languages make a comeback (e.g., Lucid).

In the PL design sense...

Even though I have still not managed to build a non-trivial app with it (due to lack of time), I would still have to nominate Mozart/Oz as an exemplary case study in the future of PL design.

The three features in particular to focus on, IMHO, are the elegant unambiguous syntax, the concurrency/distributed oriented features, and the layered kernel language architecture, in ascending order of importance.

Since we mention Oz here regularly (and have for a while), we are already ahead of the curve. ;-)

erlang vs. performance

side note: the second link in the article also goes to Tim Bray's post instead of to Steve Vinoski's

I'm not sure what the discussion on LtU was, but since the "multicore future" is upon us I've heard a lot of people thinking about looking to Erlang to address the concurrency problem to let us use the additional performance available from multiple CPU cores.

And yet it's right there in the Erlang FAQ (and was there when I looked at this five-ish years ago):

1.4. What sort of problems is Erlang not particularly suitable for?

The most common class of 'less suitable' problems is characterised by performance being a prime requirement and constant-factors having a large effect on performance. Typical examples are image processing, signal processing, sorting large volumes of data and low-level protocol termination.


Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic.

from the Erlang FAQ.

And to expand on that latter point, the next FAQ entry points out that

AXD301 has several hundred people working on it and the code volume has reached about 850 kloc of Erlang (and 1 Mloc of C/C++).

So I am highly doubtful that it is a good idea to switch to Erlang to try to improve performance of an existing non-parallel application doing multi-core. Of course, if that's not why you're interested in Erlang, then no worries.

Link fixed. Thanks.

Link fixed. Thanks.

Those are the same caveats

Those are the same caveats that come with any interpreted language. The same examples are used by Python, as I recall.

Hmm, that's a good point,

Hmm, that's a good point, and could be addressed through non-interpreted implementations (although possibly "thread"-switching cannot receive the same speedup).

However, while I didn't delve into it further to understand, I assume things are worse in Erlang due to the need to copy data.

Why copy?

Does Erlang need to copy data? Its variables are immutable, so why not share them among processes? (As long as they're running in the same memory space, that is.)

copy unnecessary

John Stracke: Does Erlang need to copy data?

No, so sharing among processes is feasible as you suggest. Erlang processes appear to have separate addresses spaces because they can't test sharing in absence of mutation; so an implementation can choose. (Makes for location independence, e.g.)

Reasoning about options for processes in absense of mutation is entertaining. :-) But it's somewhat hard to talk about. I'm not speaking from Erlang experience. This is just the line of reasoning I explored a while back, and mentioned in another LtU thread.

It's a trade-off

Message passing can be implemented either way, and has been; there have in fact been several non-copying Erlang implementations over the years. The main problem is then to avoid long garbage collection pauses.

As far as I know, the practical experience so far has been that message passing by copying actually works well enough. But perhaps that's because we have adjusted our programming styles; also, who knows whether it carries through to all future interesting cases?

Binaries are shared

Processes have separate heaps because that makes it easier to impose per-process resource limits, to protect the system from one process that allocates too much memory, as Erlang aims to enable robust systems even in the presence of buggy code.

However, binaries (the type of raw byte strings) are shared in BEAM. They are allocated in a shared area, and reference counted (no worry about cycles). I suspect most of the really large messages in an Erlang system would be binaries, because file and network IO based on binaries.


The "language, action perspective" or LAP is completely ignored by main stream computer science. Personally I think this is the right direction for language research but I don't see a language in three years.


I don't understand. What consequences might this have for programming languages?

Great Question

This is a good question with a complicated answer. The LAP research is conceptual and doesn't usually get into computer codes, and it often sounds like linguistics, but the LAP objective is communication processes between computing agents (ie programs), often in an IT (information technology) setting. Examples are e-commerce, and contracting. It is concerned with modeling, understanding and properly representing these processes. I thought that this paper from the 2005 conference was interesting for taking a broad perspective. The discussion of objectivity vs actualism touches on some of the programming issues. A quick look will give you an idea of the types of programming that would be needed.

Briefly LAP programming will emphasize several styles: reactive programming, knowledge representation, and "information" processing. LAP is about knowledge, information and data. Now for the hard part. Information implies explicit use of situation (and/or state) as well as event representation. A useful overall style should embrace all of these issues. Language metaphysics and traditional practices often divide up these issues into separate conflicting categories.

My own conclusion is that both logic programming and event programming with situation are needed in the same language. There is nothing really hard about doing this but the logic programming community won't go there, (My opinion) and the imperative community is distracted by other issues. Oddly often the same issues but from a different perspective.

LAP really is a different perspective and it conflicts with existing practices. If you believe as I do that this is fundamental and important to the future of computing then it is time for a review of all standard practices in light of this theory.

The Future is Already Here - It's Just Not Evenly Distributed

Listening to Luke talk about Erlang a couple of years ago was interesting because he clued us about real people doing real work in an esoteric but practical language.

I am more inclined to believe this sort of experience report than guesses and crystal balls...

Esoteric but not hard

In the mid-90's, I taught a standardized Erlang course to grunt programmers at Ericsson in four days. (I believe those programmers subsequently worked on the AXD-301 project, by the way.) That seemed to work out fairly well. At the end of the week, they were by no means experts, but ready to start working and continue learning. This was not by accident -- the designers kept Erlang simple and practical to make it easy to get started. I believe C/C++, to take a random example, would require far more effort to get to the same point.

So one should note that, first, even if it seems esoteric, a programming language need not be difficult to learn. Second, sometimes the big problem in getting up to speed may be to personally commit to actually going ahead and working with a language.