Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Seal writes "Erlang, originally created at Ericsson in 1986, is a functional programming language which was released as open source around 10 years ago and flourished ever since. In this Q&A, Erlang creator Joe Armstrong talks about its beginnings as a control program for a telephone exchange, its flexibility and its modern day usage in open source programs. 'In the Erlang world we have over twenty years of experience with designing and implementing parallel algorithms. What we lose in sequential processing speed we win back in parallel performance and fault-tolerance,' Armstrong said. He also mentions how multi-core processors pushed the development of Erlang and the advantages of hot swapping."

Describing Erlang as a functional language is true, but misleading. It's not a pure functional language, because there is a (mutable) process dictionary. When you call something a functional language, it implies a language modelled on Lambda Calculus. The fact that functional languages do not allow side effects (Erlang does via the process dictionary) means that they are relatively easy to parallelise implicitly. Erlang adds support for the Communicating Sequential Processes (CSP) formalism on top of a mostly-functional core language.

CSP is a very clean and simple model for describing parallel algorithms. The language enforces the restriction that no data may be both shared and mutable. The only mutable object in Erlang is the processes (which has a dictionary and some execution state). Everything else is immutable. This makes it trivially easy to write code that uses a few tens of thousands of Erlang processes (or more). These are implemented as (very) light-weight threads on top of OS threads and can easily scale up to a large number of processors, or even cluster nodes. The asynchronous aspect of the message passing means that it is not very difficult to write code that scales well across a cluster; bandwidth can be an issue, but latency generally isn't in asynchronous code.

Erlang is based on the ACTOR model, not CSP. The main practical differences between Erlang and CSP is that Erlang uses asynchronous dynamically-typed messages sent to a particular address (process id), whereas CSP systems usually deal with synchronous messages sent down a particular, typed channel. But they are both message-passing systems with the idea of removing shared mutable data, as you say.
For an implementation of CSP in the pure functional language Haskell, see my library CHP (http://www.cs.kent.ac.uk/projects/ofa/chp/).

Calling Haskell a "pure functional language" is a bit like calling C++ a "pure object-oriented language." There are parts of the Haskell language that allow you to do pure functional programming. But there are parts of the language that allow you to do things like I/O, too.

The analogy would be to call C a "low level language" even though C++ exists with high level extensions like the template system.

What makes Haskell pure is that stateful code like I/O is handled through a monad so that it doesn't leak out into the rest of the code. The purpose of a computer program is to create a side effect. So every language needs to include some capacity to induce them. What separates pure from impure is whether side effects are scattered throughout the code or isolated.

There's also the (D)ETS, (disk) erlang term storage, which gives a simple key/value store. It can be shared and mutable, depending on creation parameters.
Afaik it's mostly used for the implementation Mnesia, a native term database for erlang.

As I understand it, [D]ETS works by spawning a process for handling the storage. When you interact with a [D]ETS store, you do so via a function wrapper around this process; the data store is not aliased, only the process handle is.

Yes, but sending Mnesia messages (inserting or updating rows) causes its response to functions (select statements) with identical parameters to have different return values, hence, Mnesia isn't pure functional and calls from one part of the system can cause calls in another part of the system to have different return values. Thus people say it isn't pure functional and has side-effects.

That said, I don't have the slightest idea how you would write a database that is pure-functional, since the whole idea of

I don't have the slightest idea how you would write a database that is pure-functional

IANACS, but I think some version control systems could be pure functional databases. If the revision were a parameter to all calls, and checkins branch, then the result from the same operation (even if it were repeated) could be made to return exactly the same result (although trickier with writes).

isolation levels [slashdot.org] are also relevant? Conventional databases that store all history also relevant?

Anyone have an Erlang background, or some low level C or similar experience and live in the Chicago area (we're just south of the Loop)

I'm actively involved in a startup that is developing a large project in Erlang, looking for some additional folks to add to our team.

It's problematic trying to find people with the right skillset, since it isn't just "Erlang" we're looking for - its the general high-volume, high-availability skillset and a deep interest in learning Erlang. I didn't even know much a

This has been my absolute favorite in IT videos since I first saw it a year ago. It has that unashamed old-time dorkiness that I'm so nostalgic for. Get it in better-than-youtube quality at archive.org [archive.org].

I wish that this could become a universal precept of software design, shaping everything from OS's to desktop apps -- Joe Armstrong: "Stopping a system to upgrade the code is an admission of failure."

Trouble is, that's incredibly hard (expensive, limiting) to get right. So it only makes sense where you can't even schedule maintenance downtime or instruct the load balancer to send all requests to the other machine. So it's useful for the thing that your (and everyone else in town) single, non-redundant phone line plugs in to... and not terribly much else. Certainly not for a desktop where you're not even using it at night.

Well, a lot of people do think like this, except making it work in practice is very difficult, and implementing a system that allows code hot code upgrades usually requires so much indirection that efficiency suffers. Also, in practice, stoppiong a system to upgrade the code is a practical proposition, particularly for a home computer. Not everyone is running an ISP in their den.

Even Erlang doesn't enforce hot code swapping, you the developer still have to write the code a particular way, so that, your fu

"Erlang" is a measure of communications channel occupancy - names after the Danish mathematician and telephony researcher - but it also relates to how old telephones use to sound - when they had actual mechanical bells that would ring when a call was coming in - "erlang-a-lang-a-lang".

Only a million more projects to go....before it catches up to something like fortran.

Within the domain on which it is focussed (roughly, systems providing highly parallel communications infrastructure), Erlang is flourishing. Sure, that's not an area where there are as many individual projects as, say, scientific number crunching. And, sure, it hasn't been as long (or as early in the history of programming when there were so few competing options) as Fortran, either. So what?

I spend most of my day doing procedural and OOP. Odds are good that I'll never write a single Erlang program after I finish the book. But I guarantee that I'll be using the concepts that I'm learning for the rest of my life.

For the same reason you had to take liberal arts classes in university, everybody should learn a functional language or two.

The example that searching an MPEG looking for header frames was pretty cool. It gave me bad flashbacks to when I had to search an unmountable filesystem and extract all the JPEGs[*]. The C code I wrote was horrible...

*: I somehow managed to corrupt a VFAT partition enough that it wouldn't mount in Windows or Linux. Right after my wife unloaded the digital camera, but before she remembered to tell me to back up the photos. So I had to fix it. I scanned the entire drive, looking for the JPEG magic, and