New software
for new hardware
Elixir meetup 4.0, Lviv, December 17, 2016
Elixir introduction
Hello!
I am Anton Mishchuk
- Ruby developer at
Matic Insurance
- Elixir fan
- Author and maintainer of
ESpec BDD test framework
Github: antonmi
2
What I’d tell you
▪ No pictures, sorry
▪ No code samples
▪ No live coding
▪ Lots of philosophy
▪ Few words about Erlang and Elixir
3
The plan
▪ Software crisis?
▪ Resurrection of FP
▪ Erlang
▪ Erlang concurrency model
▪ Elixir
▪ Elixir is not Ruby
▪ You should try Elixir
4
1
Software crisis?
5
Common characteristic of
present software
▪ low quality
▪ very inefficient
▪ difficult to maintain
6
Nathan Myhrvold’s laws
▪ “Software is a gas”
▪ “Software grows until it becomes
limited by Moore’s Law”
▪ “Software growth makes Moore’s
Law possible”
▪ “Software is only limited by
human ambition and expectation”
7
Nathan Myhrvold, formerly CTO at Microsoft
Niklaus Wirth’s Law:
“Software gets slower
faster than hardware
gets faster”
8
Niklaus Wirth, computer scientist,
designer of several PL (incl. Pascal)
What next?
9
▪ Better hardware?
or
▪ Better software?
10
We are experiencing a period
of “dramatic changes”
▪ New hardware!
▪ New software!
11
New hardware:
▪ Multicore systems
▪ ASIC (Application-specific
integrated circuit)
▪ FPGA (Field-programmable gate
array)
12
“The von Neumann Syndrome”
New software:
Multicore crisis:
To take advantage of the additional
cores most applications have to be
rewritten
13
2
Resurrection of FP
14
Functional programming
FP is a programming paradigm
that treats computation as the
evaluation of mathematical
functions.
FP: Data structures manipulated
through functions
OOP: Objects manipulated through
methods
15
FP concepts
▪ High-order functions
▪ Pure functions
▪ Recursions
▪ Lazy evaluations
▪ Currying
▪ Closures
16
History
FP:
▪ Lisp, 1950s
▪ APL, 1960s
▪ Haskell, late 80s
▪ Erlang, 1986
OOP:
▪ Simula, 1960s
▪ Smalltalk, 1970s
▪ Java, Ruby, 1995
17
CPU:
▪ Single-processor machines
▪ 50%/year clock speed growth
▪ From ~10MHz to ~1GHz
RAM:
▪ Relatively expensive and slow
▪ $100/1Mb in 1990. $1/1Mb in 2000
▪ CPU cache
OOP dominating in 90s
18
▪ Is OOP the only right way to to
create software?
▪ Is OOP the RIGHT way?
19
Why OO sucks?
(c) Joe Armstrong
20
▪ Functions do things
▪ Data structures just are
Since functions and data structures
are completely different types of
animal it is fundamentally
incorrect to lock them up in the
same cage.
Objection 1:
Data structure and functions
should not be bound together
21
▪ Should “time” to be an instance
of some type?
▪ Should a simple integer number to
be an instance of some type?
Objection 2:
Everything has to be an object
22
▪ lots of types with limited amount
of specific functions
Isn't it better have a smallish
number of ubiquitous data types and
a large number of small functions
that work on them?
Objection 3:
Data type definitions are
spread out all over the place
23
The state is hidden and visible
only through access functions.
State is the root of all evil!
Objection 4:
Objects have private state
24
Why OO was popular?
(c) Joe Armstrong
25
▪ It was thought to be easy to
learn.
▪ It was thought to make code reuse
easier.
▪ It was hyped.
▪ It created a new software
industry.
Why OO was popular?
(c) Joe Armstrong
26
I see no evidence of 1 and 2.
Reasons 3 and 4 seem to be
the driving force behind the
technology.
27
If a language technology is so bad
that it creates a new industry to
solve problems of its own making then
it must be a good idea for the guys
who want to make money.
28
3
Erlang
29
▪ Elixir compiler is written in
Erlang
▪ Both Elixir and Erlang compiles
into BEAM byte code
Elixir == Erlang
30
▪ Ericsson, 1986
▪ Joe Armstrong, Robert Virding and
Mike Williams
▪ Open-sourced in 1998
▪ Telecom systems (telephone
switches)
▪ The latest version is 19.1
Erlang
31
▪ Fault tolerance
▪ Scalability
▪ Distribution
▪ Live update
Erlang buzzwords
32
▪ Ericsson
▪ WhatsApp
▪ Facebook
▪ Amazon
▪ Bet365
▪ Demonware
▪ ...
Companies using Erlang
33
▪ Modules
▪ Functions
▪ Primitive data types:
atoms, integers, floats, tuples,
lists, maps, strings, binaries,
records, references, pids, ports,
funs.
Erlang components
34
4
Erlang concurrency model
35
▪ Native threads
▪ Green threads
▪ Event loop
It is not about:
36
▪ lightweight processes
▪ with isolated memory
▪ communication via messages
It is about “actors”
37
In response to a message actor
receives, can concurrently:
▪ send a finite number of messages
to other actors
▪ create a finite number of new
actors
▪ Set the “state” to be used for
the next message it receives
Actors
38
▪ Controlled by BEAM VM
▪ ~ 1µs to create process
▪ ~ 1kB memory per process
▪ ~ 1µs to pass a message
Erlang actors
39
▪ encapsulate state
▪ communicate with other actors by
exchanging messages
More OO than objects
40
▪ Tools
▪ Libraries
Design principles:
▪ Workers and Supervisors
▪ GenServer, GenFSM
▪ Event Handler and Manager
▪ Application
Erlang OTP
41
5
Elixir
42
▪ Jose Valim, 2012
▪ Current version 1.3
▪ Hex.pm
▪ >3000 packages, ~20000 down/day
▪ Elixir Conf EU, Elixir Conf US
▪ Elixir Companies
▪ Phoenix web framework
(2M websocket conns)
Elixir
43
What is Elixir?
44
Elixir is Erlang with pretty syntax
and metaprogramming
▪ Consistent stdlib
▪ Pipe operator
▪ Tools (mix, iex, logger)
Elixir metaprogramming
45
▪ Easy code sharing
▪ Perfect Ruby-like DSLs
6
Elixir is not Ruby
46
Elixir is functional
47
▪ Function is a primary Elixir
abstraction.
▪ Data is immutable
▪ Minimal state manipulation
Ruby is OO language
with some FP features
48
▪ Procs, lambdas
▪ No FP optimizations
▪ Data is mutable
Concurrency model
49
In Ruby, one moves through a
monolithic call stack, manipulating
objects. Threads or fibers uses the
same memory heap.
Elixir processes have their own
heaps, and the VM collects process'
garbage independently of each
other.
What is the same?
50
“programmer happiness” philosophy:
▪ Pretty syntax
▪ Good documentation
▪ Tools for easy development
7
You should try Elixir
51
Think about future software
52
▪ Multi-core computers
▪ IoT with up to 30 billion devices
to be online by 2020
Double paradigm switch
53
▪ Functional programming
▪ Actor concurrency model
You’ll found it exciting
54
▪ It’s easy to get started
▪ Lots of tutorials
▪ Nice documentation
▪ Great community
Thanks!
ANY QUESTIONS?
55

Elixir intro

  • 1.
    New software for newhardware Elixir meetup 4.0, Lviv, December 17, 2016 Elixir introduction
  • 2.
    Hello! I am AntonMishchuk - Ruby developer at Matic Insurance - Elixir fan - Author and maintainer of ESpec BDD test framework Github: antonmi 2
  • 3.
    What I’d tellyou ▪ No pictures, sorry ▪ No code samples ▪ No live coding ▪ Lots of philosophy ▪ Few words about Erlang and Elixir 3
  • 4.
    The plan ▪ Softwarecrisis? ▪ Resurrection of FP ▪ Erlang ▪ Erlang concurrency model ▪ Elixir ▪ Elixir is not Ruby ▪ You should try Elixir 4
  • 5.
  • 6.
    Common characteristic of presentsoftware ▪ low quality ▪ very inefficient ▪ difficult to maintain 6
  • 7.
    Nathan Myhrvold’s laws ▪“Software is a gas” ▪ “Software grows until it becomes limited by Moore’s Law” ▪ “Software growth makes Moore’s Law possible” ▪ “Software is only limited by human ambition and expectation” 7 Nathan Myhrvold, formerly CTO at Microsoft
  • 8.
    Niklaus Wirth’s Law: “Softwaregets slower faster than hardware gets faster” 8 Niklaus Wirth, computer scientist, designer of several PL (incl. Pascal)
  • 9.
  • 10.
    ▪ Better hardware? or ▪Better software? 10
  • 11.
    We are experiencinga period of “dramatic changes” ▪ New hardware! ▪ New software! 11
  • 12.
    New hardware: ▪ Multicoresystems ▪ ASIC (Application-specific integrated circuit) ▪ FPGA (Field-programmable gate array) 12 “The von Neumann Syndrome”
  • 13.
    New software: Multicore crisis: Totake advantage of the additional cores most applications have to be rewritten 13
  • 14.
  • 15.
    Functional programming FP isa programming paradigm that treats computation as the evaluation of mathematical functions. FP: Data structures manipulated through functions OOP: Objects manipulated through methods 15
  • 16.
    FP concepts ▪ High-orderfunctions ▪ Pure functions ▪ Recursions ▪ Lazy evaluations ▪ Currying ▪ Closures 16
  • 17.
    History FP: ▪ Lisp, 1950s ▪APL, 1960s ▪ Haskell, late 80s ▪ Erlang, 1986 OOP: ▪ Simula, 1960s ▪ Smalltalk, 1970s ▪ Java, Ruby, 1995 17
  • 18.
    CPU: ▪ Single-processor machines ▪50%/year clock speed growth ▪ From ~10MHz to ~1GHz RAM: ▪ Relatively expensive and slow ▪ $100/1Mb in 1990. $1/1Mb in 2000 ▪ CPU cache OOP dominating in 90s 18
  • 19.
    ▪ Is OOPthe only right way to to create software? ▪ Is OOP the RIGHT way? 19
  • 20.
    Why OO sucks? (c)Joe Armstrong 20
  • 21.
    ▪ Functions dothings ▪ Data structures just are Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage. Objection 1: Data structure and functions should not be bound together 21
  • 22.
    ▪ Should “time”to be an instance of some type? ▪ Should a simple integer number to be an instance of some type? Objection 2: Everything has to be an object 22
  • 23.
    ▪ lots oftypes with limited amount of specific functions Isn't it better have a smallish number of ubiquitous data types and a large number of small functions that work on them? Objection 3: Data type definitions are spread out all over the place 23
  • 24.
    The state ishidden and visible only through access functions. State is the root of all evil! Objection 4: Objects have private state 24
  • 25.
    Why OO waspopular? (c) Joe Armstrong 25
  • 26.
    ▪ It wasthought to be easy to learn. ▪ It was thought to make code reuse easier. ▪ It was hyped. ▪ It created a new software industry. Why OO was popular? (c) Joe Armstrong 26
  • 27.
    I see noevidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. 27
  • 28.
    If a languagetechnology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money. 28
  • 29.
  • 30.
    ▪ Elixir compileris written in Erlang ▪ Both Elixir and Erlang compiles into BEAM byte code Elixir == Erlang 30
  • 31.
    ▪ Ericsson, 1986 ▪Joe Armstrong, Robert Virding and Mike Williams ▪ Open-sourced in 1998 ▪ Telecom systems (telephone switches) ▪ The latest version is 19.1 Erlang 31
  • 32.
    ▪ Fault tolerance ▪Scalability ▪ Distribution ▪ Live update Erlang buzzwords 32
  • 33.
    ▪ Ericsson ▪ WhatsApp ▪Facebook ▪ Amazon ▪ Bet365 ▪ Demonware ▪ ... Companies using Erlang 33
  • 34.
    ▪ Modules ▪ Functions ▪Primitive data types: atoms, integers, floats, tuples, lists, maps, strings, binaries, records, references, pids, ports, funs. Erlang components 34
  • 35.
  • 36.
    ▪ Native threads ▪Green threads ▪ Event loop It is not about: 36
  • 37.
    ▪ lightweight processes ▪with isolated memory ▪ communication via messages It is about “actors” 37
  • 38.
    In response toa message actor receives, can concurrently: ▪ send a finite number of messages to other actors ▪ create a finite number of new actors ▪ Set the “state” to be used for the next message it receives Actors 38
  • 39.
    ▪ Controlled byBEAM VM ▪ ~ 1µs to create process ▪ ~ 1kB memory per process ▪ ~ 1µs to pass a message Erlang actors 39
  • 40.
    ▪ encapsulate state ▪communicate with other actors by exchanging messages More OO than objects 40
  • 41.
    ▪ Tools ▪ Libraries Designprinciples: ▪ Workers and Supervisors ▪ GenServer, GenFSM ▪ Event Handler and Manager ▪ Application Erlang OTP 41
  • 42.
  • 43.
    ▪ Jose Valim,2012 ▪ Current version 1.3 ▪ Hex.pm ▪ >3000 packages, ~20000 down/day ▪ Elixir Conf EU, Elixir Conf US ▪ Elixir Companies ▪ Phoenix web framework (2M websocket conns) Elixir 43
  • 44.
    What is Elixir? 44 Elixiris Erlang with pretty syntax and metaprogramming ▪ Consistent stdlib ▪ Pipe operator ▪ Tools (mix, iex, logger)
  • 45.
    Elixir metaprogramming 45 ▪ Easycode sharing ▪ Perfect Ruby-like DSLs
  • 46.
  • 47.
    Elixir is functional 47 ▪Function is a primary Elixir abstraction. ▪ Data is immutable ▪ Minimal state manipulation
  • 48.
    Ruby is OOlanguage with some FP features 48 ▪ Procs, lambdas ▪ No FP optimizations ▪ Data is mutable
  • 49.
    Concurrency model 49 In Ruby,one moves through a monolithic call stack, manipulating objects. Threads or fibers uses the same memory heap. Elixir processes have their own heaps, and the VM collects process' garbage independently of each other.
  • 50.
    What is thesame? 50 “programmer happiness” philosophy: ▪ Pretty syntax ▪ Good documentation ▪ Tools for easy development
  • 51.
  • 52.
    Think about futuresoftware 52 ▪ Multi-core computers ▪ IoT with up to 30 billion devices to be online by 2020
  • 53.
    Double paradigm switch 53 ▪Functional programming ▪ Actor concurrency model
  • 54.
    You’ll found itexciting 54 ▪ It’s easy to get started ▪ Lots of tutorials ▪ Nice documentation ▪ Great community
  • 55.