Erlang: Practical FunctionalProgramming

Functional Thursday, Taipei

December 11, 2014

Jake Morrison <jake@cogini.com>

Philosophy of Erlang

Erlang was designed for writing concurrentprograms that 'run forever' - Joe Armstrong

Let it fail. Have another process deal with it.

Fault tolerance requires at least *two* computers.

Origins

Designed by Ericsson as a high level languageto be used to build highly reliable telecomsystems.

Today

"Internet scale" applications such as WhatsApp Financial services, e.g. high frequency trading Embedded systems

Virtual Machine

Similar model to Java Implements all the "hard stuff" needed to build

scalable systems, e.g. networking, lightweightprocesses and message passing, soprogrammers can focus on the high levelfunctionality of of the systems they arebuilding.

The Erlang Language

-module(test).

-export([fac/1]).

fac(0) -> 1;

fac(N) -> N * fac(N-1).

Elixir

defmodule ModuleName do

def hello do

IO.puts "Hello World"

end

end

Lisp Flavoured Erlang

(defmodule ring

(export

(main 1)

(roundtrip 2)))

(defun roundtrip (id pid)

(receive

(1

(io:fwrite '"Result: ~b~n" (list id))

(erlang:halt))

(data

(! pid (- data 1))

(roundtrip id pid))))

OTP Framework

Building blocks for Network services Process supervision finite state machines Event handling

Tools Monitoring Debugging

Network Services Programming Paradigms

Distributed Objects

J2EE and remote method invocation (RMI) CORBA

Locking Shared state Amdahl's law

Events and Callbacks

Node.js Twisted Python

Hey, I have some bytes for you. Non-blocking I/O Easier to reason about Limited concurrency Scalability limits, only uses one CPU

Async Messaging

Tuxedo transaction processing system Message queuing Erlang Communicating Sequential Processes

Internet Scale Systems

Performance vs Scalability

Our Multi Core Future

Stream processing

Pattern matching

Varying load

Denial of service attacks

Back to Erlang

Features

Message passing

No sharing of data except via reliable persistent storage systems

Built in databases, in memory and on disk

Distributed between nodes

Lightweight processes, use as many as you like to model your system the easiest way

A process for every truly concurrent event

Complete isolation between processes, a failure in one process doesn't affect others

Location transparency, scale across physical servers with the same design

Failure can happen at any time

Don't be defensive, let it crash

Acknowledgments, retries

Supervision

Name registry

Hot code updates

Simple Data Types

Integers

Floats

Atoms

Strings

Binaries

Tuples, Lists

Single assignment / patternmatching

A = 1

1 = 1

1 = 2

Value = {2, 4}

{Width, Height} = {2, 4}

[Head|Tail] = [1,2,3,4]

Functional Programming

calculate_area({square, Size}) ->

Size * Size;

calculate_area({circle, Radius}) ->

Pi = 3.14,

Pi * Radius * Radius;

calculate_area(_Unknown) ->

{error, unkown}.

Higher order programming

List comprehensions

Map, fold

Spawning Processes

F = fun() ->

io:format(“hi”)

end,

Pid = spawn(F).

Message Passing

Pid ! Message

Pid ! {do_task, run_home}

Pid ! 2

receive

receive

Pattern1 [when Guard1] -> Expressions1;

Pattern2 [when Guard2] -> Expressions2

End.

Messages are contained in a process’s inbox.

Putting it Together

loop(State) ->

receive

{Sender, Message} -> io:format(Message), Sender ! ok

loop(State)

end

end.

Questions?

Doing something useful

http://www.littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails/