3. Erlang
• 1987 - First version written in Prolog.
Good but slow
• Early ’90 - BEAM
• 1992 - Erlang in production
• In 1998 Ericsson announced the
AXD301 switch, containing over a
million lines of Erlang and reported to
achieve a high availability of nine “9"s.
• 1999 Ericsson banned the use of
Erlang
• 2004 Ericsson lifted the ban
6. COP Languages
In languages like <noname> they forgot about concurrency. It either
wasn’t designed in from the beginning or else it was added on as an
afterthought.
Armstrong, 2002
7. COP Languages
• Processes are truly independent
• No penalty for massive parallelism
• No unavoidable penalty for distribution
• Concurrent behaviour of program same on all OSs
• Can deal with failure
8. COP is nice
• The world is parallel
• The world is distributed
• Things fail
• Make more powerful by adding more processors
• Our brain intuitively understand parallelism
10. Open Telecom Platform
• Delivered with Erlang and written in Erlang, it contains:
• an Erlang interpreter (which is called BEAM)
• an Erlang compiler
• a protocol for communication between servers (nodes)
• An Object Request Broker
• a static analysis tool called Dialyzer
• a distributed database server (Mnesia)
• many other libraries and utilities
11.
12. Elixir
• R&D project form
Plataformatec (2011)
• His goals were to enable
higher extensibility and
productivity in the
Erlang VM while keeping
compatibility with
Erlang's ecosystem
13. Features
• Compiles to bytecode for the BEAM
• Functional language, everything is an expression
• Erlang functions can be called without costs
• Metaprogramming with macros
• Polymorphism via a mechanism called protocols and
behaviours
• Pattern matching
• Expressive language that programmers love (like Ruby!)
14. Elixir today
• Version 1.6.5
• New version every 6 months (1.7 in July)
• Hex package management (~6k packages)
• Vibrant community
16. Processes
• Everything runs in a process
• Process is isolated
• Process communicate using messages
• Inside a process code runs in a single thread
17. GenServer
• The basic behaviour for a general purpose process
• Has state
• A “public interface” (client api vs. server callbacks)
• Callbacks to handle messages and send responses
• Terminate callback
18. GenServer
• init(args) :: {:ok, state}
A sort of “constructor” for the server
• handle_call(request, from, state) ::
{:reply, reply, new_state}
Handle synchronous messages
• handle_cast(request, state) :: {:noreply,
new_state}
Handle asynchronous messages
Redux?
19. GenServer and…
• GenStage: Producer-Consumer pipelines
• GenStatem: Event driven state machine
• Agent: State management
20. Actor model
• GenServer is the basic block for the actor model
• Code inside GenServer is single thread
• GenServer has it’s own message queue
• GenServer can create other Genservers
21. Supervisor
• A process to monitor other processes
• Handle failures and restarts child as needed
22. Supervisor
• Restarting strategy
• :one_for_one - if a child process terminates, only
that process is restarted.
• :one_for_all - if a child process terminates, all other
child processes are terminated and then all child
processes are restarted.
• :rest_for_one - if a child process terminates, the
“rest” of the child processes are terminated. Then the
terminated child process and the rest of the child
processes are restarted.
23. Applications
• Applications are a bundle of sub-application
• Application consists of a manifest
• Dependencies are sub-application
• Usually it starts the main supervisors and the
dependent applications
24. Other gems
• Macros
• Hot code swapping
• Umbrella projects
• Remote debugging and inspection
• Community ❤
25. Tooling
• mix is rake for Elixir
• https://hex.pm is the package registry
• Spec and Dyalizer
• Release with distillery (erts inside…no
prerequisites!)