Teaching Erlang as part of a paper -- advice sought

[Richard O'Keefe]

This year I am in the happy position of teaching a paper on
concurrent programming.  I propose to start by teaching Erlang,
as being by far the simplest concurrent programming language I
know (except possibly Occam, but while the restrictions in
Occam are _motivated_, they are still quite painful, and make
the language harder to use).

However, I've never actually _taught_ Erlang before.
These are 4th year students with Java and C.  Last year in a
class at the same level one group did an assignment in Erlang
without needing to be taught.

Has anyone tried more than one Erlang book?  What works well?

I propose to explain Erlang as
	- take a minimal programming language (which means
	  pretty much lambda calculus)
	- add a few simple data structures (integers, floats,
           lists, tuples, atoms)
	- add pattern matching
	- add minimal support for concurrency
	  (processes and process IDs, !, receive)
	- add support for large scale programming (modules)
	- add support for practical programming (testing, debugging,
	  monitoring, most of which I don't plan to cover)
	- add support for distribution
	  (nodes, unreliable messaging, timeouts, &c)
	- add support for persistent data (might/might not mention)
but I'm really only interested in Erlang as a means to an end.

What I am *really* interested in is "how do we design and build
reliable concurrent systems".  My use of Erlang for this paper is
purely pragmatic.  I have considered and dismissed C (although
POSIX threads will make an appearance near the end, perhaps I
should call this "C THreads, Unsafe Libraries, and Hazardous
Undertakings" programming (:-)), C++, Cilk, OpenMP (although I
think I do have to mention it), Ada (lots going for it including
SPARK/Ada, but I'd have to spend more time teaching Ada than Erlang),
Limbo, Go, Concurrent ML, Haskell, Occam, various Scheme dialects,
Java, and C# amongst others.  I believe Erlang will get them writing
working concurrent code sooner than any of the others.

Here there is a dispute between me and one of the other lecturers
in the department, who will not be involved in this paper, at least
not this year.  I want the students to start learning about
concurrent programming in a language in which data races (at least
data races not involving external resources) are simply impossible.
He thinks they should (a) learn what a data race looks like the hard
way early on and (b) learn not be be afraid of data races, because
the low level locking code on x86-64 Linux apparently has a benign
data race.

"How do we design and build reliable concurrent systems" is obviously
an opportunity to exploit some of the hard thinking that went into
Erlang/OTP and teach the "behaviours", although the first "design
pattern" I want to teach is acyclic networks of pipes.  The question is
"how do we look at a problem and see the concurrency there", and if
anyone has any recommendations I'd be very pleased to get them.

A *huge* thank you to Joe Armstrong and the Erlang/OTP team for
all their work.