Programming Erlang

Preview:

DESCRIPTION

(Given to the Vancouver Erlang and Ruby/Rails Meetup groups on June 17, 2009.) A follow-up to last month's "Intro to Erlang" (http://www.slideshare.net/kenpratt/intro-to-erlang), this talk will dive into the core components of the Erlang programming language, including processes, pattern matching, and message passing. Unlike the previous talk, it will be light on hype and loaded with code samples. If you missed the previous talk, you might want to run through the slides quickly at http://www.slideshare... before coming to get a brief overview Erlang. Speaker Bio: Ken Pratt has been developing software for the web for over 10 years. He fell in love with Ruby four years ago, but is still passionate about learning other languages and platforms. He has developed scalable web services for Electronic Arts, built Rails-based web applications since pre-1.0, and been featured in interactive art installations.

Citation preview

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

Recommended