Programming Erlang
June 17, 2009
Ken Pratt
http://kenpratt.net/

Erlang philosophy
Simple language
Ultra-lightweight concurrency
No shared state (and no locks, no mutexes)
<3 asynchronous message passing
Processes should be able to run forever

The language
Functional
Strong, dynamic typing
NO shared state(!!) (and no mutable variables)
Pattern matching on steroids
<3 tail recursion
Compiled to bytecode, runs on VM

Basic data types
Integers
Floats
Atoms
Tuples
Lists

Integers
No maximum size (a growing integer will keep eating
memory until you run out of RAM -- that’s a big
number!)

Floating-point numbers
64-bit precision

Atoms
Non-numerical constants
Like Ruby symbols
“Natural” atoms: [a-z][a-zA-Z0-9_@]+
Otherwise, anything single-quoted is an atom

Tuples
Fixed-length sets of elements
Used sort of like C/C++ structs, for passing structured
data around

Lists
Variable-length collections of elements
Usually homogenous, but can be heterogeneous (like
Ruby)
Library of list operations (foreach, map, filter, sort, etc)

NOT Types
Booleans
Strings (oh dear!!)
Hashes
Classes & objects ;)

Booleans
Just a special case of atoms

Strings
Just a list of integers in the range 0..255
Double quotes are syntactic sugar
Unicode support added March 2009 in Erlang R13A
io:format and io_lib:format for printf-like formatting

Hash tables/dictionaries
Property list
Just a list of two-element tuples
“proplists” library has common functionality
“dict” library is a heavier, more feature-full option

Classes & objects
Erlang is functional, and doesn’t have classes/objects
However, it has records, which are a “named tuple”
They are a compile-time feature, which is ANNOYING

Functions
Named functions & anonymous functions (funs)
Differ by arity (convention is [func_name/arity])
myfun/1 and myfun/2 are different functions

Pattern matching
Pattern matching is awesome
“=” is NOT an assignment operator! It is a pattern
match operator
Unbound variables will get bound during the match

Nested patterns
You can match nested structures

Matching list elements
It’s easy to grab one or more elements from a list

Matching function clauses
Can have multiple named functions with the same arity,
using pattern matching on arguments

Matching + functions

Conditionals
Supports case and if statements, but they are very
different from other languages
Both have pattern matching support
Both use “guards”, which are simple operations like
comparisons (<, >, etc), is_atom, length(List), etc

Case statements

If statements
Avoid them, as case is cleaner, even for true/false

Processes
Erlang processes are sort of like threads, but without
the headaches of shared state

Messages
Each process has a message queue
Easy to send messages around
Common convention is to send a tuple where first
element is an atom with the message type

Receiving messages
Use a receive block to pull a message off the queue
Usual pattern is a server “loop” that waits for messages

Synchronous messages
Asynchronous by default
But easy to implement synchronous messages
Need to pass own pid along with message, so server
can reply (self() returns pid of current process)

Actor model
Erlang is built around the Actor model
Think of a process like an object
It handles incoming messages (like calling methods
with arguments)
It sends replies (like method return values)
It incapsulates state (passed around explicitly)

Architecture
= light-weight process with a built-in mailbox

Distributed architecture
= light-weight process with a built-in mailbox

Networking patterns
Erlang has built-in functions for common network
operations, such as RPC
OTP (“Open Telecom Platform”) libraries provide
frameworks for many architecture patterns, such as
servers and state machines
gen_server is most common -- supports synchronous
and asynchronous calls, and server state

Where to start
“Programming Erlang”
by Joe Armstrong
(creator of Erlang)
Slides & videos online!
(I’ll post the link to the mailing list)
http://www.erlang-factory.com/
conference/SFBayAreaErlangFactory2009