Erlang

Now we have Joe Armstrong - an invited speaker to talk to us about Erlang. I've always been curious about Erlang - Patrick Logan has said good things about it, for instance. He's worked in Smaltalk, and likes it. His work has been in telephony, and Smalltalk was a bit slow for their purposes (this is way back). Ordered a Tektronix Smalltalk machine (that's how far back :) ) - but there was a two month wait for it.

In the interim, he fell into Prolog by accident. By the time the Smalltalk machine arrived, he was more interested in working with Prolog. He gave the Smalltalk machine away, and Objectory came out of that donation. In further experimentation, he added concurrency to Prolog - and this is where Erlang was born - Joe is the inventor of Erlang. He's curently a senior system architect at Ericsson AB.

One thing that Erlang is very good at is creating large numbers of processes. In Java, for instance, processes map down to the OS (threads) - and that takes away predictable behavior. So what you want is:

• create large numbers of processes
• work the same on different OS's
• are garbage collected
• are location transparent
• cannot damage other processes
• are defined in the language
• creating and destroying processes should be lightweight

Niall Dalton: Erlang is Smalltalk the way Alan Kay wanted it to be - this got a nice laugh from the audience :)

Assertion: To make a fault tolerant system, you need at least two computers. That means that you are doing distributed programming. To simplify the problems, have:

• No sharing
• pure message passing
• no locks

Sharing gets in the way of fault tolerance. This gives us Concurrency Oriented Programming:

• A style where concurrency is used to structure the programming
• large number of processes
• complete isolation of processes
• no sharing of data
• location transparency
• pure message passing

So the design rules:

• Identify the concurrent operations in the problem
• identify the message channels
• write down the set of messages seen on each channel
• write down the protocols
• write down the code

Try to make the design isomorphic to the problem - i.e., a 1:1 correspondence between process/message structure in the model and the problem.

In 1998, Erlang got banned at Ericsson, due to a "we must use standard languages" wave (sounds familiar). The upshot was, Erlang got open sourced, and the Erlang folks formed Bluetail. Bluetail was later acquired.

The basic concept here: systems should be black boxes that can communicate - failures in one black box should not crash another black box. This leads to making all communication asynchronous. The problem domain:

• Highly concurrent - hundreds of thousands of parallel activities
• Real time
• Distributed
• High Availability - down times of minutes/year - never down
• Complex Software - millions of lines of code
• Continuous Operation - years
• Continuous Evolution
• In service upgrade

So to get this:

Concurrency	processes
Error encapsulation	isolation
fault detection	what failed
Fault identification	why it failed
Live code upgrade	evolving systems (multiple versions at same time)
Stable storage	crash recovery

Isolation is key here: It's why hardware components are easier to build. Erlang is designed to operate concurrently via message passing, with isolation. So:

Processes have share nothing semantics and data must be copied. Message passing is the only way to exchange data. Message passing is asynchronous. My program should not be able to crash your program.

Programming for Errors: If you can't do what you want to do, try and do something simpler :) Using these techniques, they've built a 9 nine's reliable GPRS system in Europe.

Technorati Tags: esug, smalltalk, erlang