Why Erlang? - Speaker Deck

Slide 1

Slide 1 text

Why Erlang? Trevor Brown

Slide 2

Slide 2 text

Trevor Brown Sarasota, Florida Erlang, Elixir, Ruby, JavaScript Software Developer at Voalte

Slide 3

Slide 3 text

Reliability “the quality of being trustworthy or of performing consistently well.” – Google Dictionary ● Characteristic of good server software ● Something that must be addressed during development

Slide 4

Slide 4 text

Potential Faults - Hardware ● Hardware faults will be encountered ● Transient faults – Loss of power – Loss of network connectivity – Disk full ● Permanent faults – Hard disk failure ● Human error

Slide 5

Slide 5 text

Potential Faults - Software ● Again, software faults will be encountered ● Unanticipated hardware failures ● Software bugs present in other systems ● Software bugs in your own code

Slide 6

Slide 6 text

Fault Tolerance ● Reliable software must be able to handle faults in an intelligent way – Sometimes crashing – Sometimes retrying the failed action – Ignoring faults is always bad ● Without some sort of fault tolerance larger software systems will be brittle, crashing the first time a fault occurs

Slide 7

Slide 7 text

Most Modern Languages Don’t Handle Faults Well

Slide 8

Slide 8 text

Most Languages ● Weren’t designed with fault tolerance in mind ● Don’t have constructs for dealing with unexpected exceptions ● Not suited for long-running server software ● Usually rely on other OS-level tools when faults crash the application

Slide 9

Slide 9 text

Let’s look at how fault tolerance is handled in hardware systems...

Slide 10

Slide 10 text

Data centers have systems in place that ensure their servers remain online

Slide 11

Slide 11 text

Data Center Power Supply Rack PDU PDU PDU UPS ATS GEN Utility Transformer Utility Transformer GEN ATS UPS PDU PDU PDU

Slide 12

Slide 12 text

Fault tolerance is achieved through isolation and redundancy

Slide 13

Slide 13 text

Fault removal is also necessary for long term reliability

Slide 14

Slide 14 text

Software reliability can be achieved the same way

Slide 15

Slide 15 text

This cannot be done with most language runtimes

Slide 16

Slide 16 text

Language Limitations ● Single thread of execution* ● Code that is executing has full control – May crash the process – May meddle with any data ● Single thread limits error handling abilities

Slide 17

Slide 17 text

Error Handling Insufficiencies ● Unhandled exceptions always crash the application – Exceptions must be caught if the application is to continue running ● Some exceptions cannot reasonably be handled inline – Software bugs are a common source of faults and often result in exceptions – Some potential exceptions are intentionally ignored – Impossible to enumerate all potential exceptions

Slide 18

Slide 18 text

Caused by Lack of Isolation ● Single thread of execution is the biggest weakness – Everything is under it’s control – No redundancy, we don’t have other threads of execution for backup ● When a function calls another function it is passing it the all powerful thread of execution – There is no way for the original caller to take back this power – Rest of the application is powerless and must wait for the function to return – No, it’s not sending it a message

Slide 19

Slide 19 text

How do we solve this?

Slide 20

Slide 20 text

True Isolation ● Multiple threads of execution ● Each with their own memory ● No shared memory between them ● Preemptive scheduling so CPU time is shared fairly among them

Slide 21

Slide 21 text

Can support for this be added to existing languages via libraries?

Slide 22

Slide 22 text

Limitations of Libraries ● Libraries can't enforce system wide-guarantees – Immutable data – Memory safety – Type safety ● Libraries can't change architecture of the underlying language – Optimizations – Language constructs

Slide 23

Slide 23 text

A new language is needed when we need to enforce additional constraints on our programs OR When features are needed that must be provided by the underlying language

Slide 24

Slide 24 text

Erlang

Slide 25

Slide 25 text

How does Erlang solve this?

Slide 26

Slide 26 text

Erlang Processes ● Not correlated with threads or processes – Not the same as an OS process ● Each have their own memory – Each process is garbage collected individually ● Preemptively scheduled – Busy processes won’t hog CPU time

Slide 27

Slide 27 text

Erlang Processes ● Identified by ID and optionally by name ● Can communicate by placing messages in the mailbox of the recipient process ● Can be created on the fly with the spawn command ● Can be monitored by another process so the process can take action when the process crashes ● Can be linked to another process so both processes crash when an exception occurs

Slide 28

Slide 28 text

Erlang OTP ● Processes alone aren’t enough – Processes only limit the effects of faults – Processes cannot restore faulting systems ● OTP is a collection of libraries and tools for building systems that can recover from transient faults automatically

Slide 29

Slide 29 text

Erlang VM ● Concurrent ● Distributed ● Mostly functional ● Dynamically typed ● Hot code loading

Slide 30

Slide 30 text

Language Priorities Runtime guarantees syntax ecosystem developer friendliness

Slide 31

Slide 31 text

Erlang Language Constructs ● Spawning processes ● Message passing between processes ● Recursion ● Pattern matching

Slide 32

Slide 32 text

Processes are Actors ● Ends up feeling like a better OO ● Best implementation of Alan Kay's vision as he described it at OOPSLA 1997 ● Destroys some OO misconceptions that have been forced on us by our languages

Slide 33

Slide 33 text

Erlang Basics

Slide 34

Slide 34 text

Data Types ● All data is immutable Atoms ● Atoms are just like symbols in Ruby ● No boolean type, just the atoms true and false hello_world a true % No booleans

Slide 35

Slide 35 text

Binaries and Numbers ● % Binaries <<97,98,99>> <<"abc">> % Integers 12 % Floats 23.5

Slide 36

Slide 36 text

Tuples ● {one, two, three} % Tuples are contiguously in memory {1,2,3,4} % We can access individual items with element element(2, {1,2,3,4}) % => 2

Slide 37

Slide 37 text

Lists ● No array type, only linked lists. ● Each item contains a pointer to the next them [1,2,3] Letters = [a,b,c] % Items can be added to the front of the % list easily [d|Letters] % => [d,a,b,c]

Slide 38

Slide 38 text

Strings (Still Lists) ● No true string type, strings are lists of character codes "Joe" % => "Joe" % still just a list % $a returns the character code for a $a % => 97 % If lists only contain character codes % they will be printed as strings [$a, $b, $c] % => "abc"

Slide 39

Slide 39 text

More Data Types... ● % Maps #{key => value} % Records -record(user, {username, email, password}). #user{ username="Joe", email="[email protected]" }.

Slide 40

Slide 40 text

Modules ● Modules must be defined in a file with the same name -module(demo). % Functions must be exported to be used % outside module -export([test/0]). % Function here...

Slide 41

Slide 41 text

Functions ● Functions are identified by name and arity % add/2 has two clauses add(0, 0) -> 0; add(X, Y) -> X + Y. % add/3 has one clause add(X, Y, Z) -> X + Y + Z.

Slide 42

Slide 42 text

Pattern Matching

Slide 43

Slide 43 text

Pattern Matching a = a % => a a = b % => ** exception error: no match of right hand side value b Letter = a % => a Letter % => a

Slide 44

Slide 44 text

Pattern Matching Tuples ● {ok, Value} = {ok, "foo bar baz"} Value % => "foo bar baz" {ok, Value} = {error, crashed} % => ** exception error: no match of right hand side value crashed

Slide 45

Slide 45 text

Pattern Matching Lists ● [Head|Tail] = [1,2,3] Head % => 1 Tail % => [2,3] [First,Second,Third] = [1,2,3] Second % => 2 [One,Two] = [1,2,3] % ** exception error: no match of right hand side value [1,2,3] [First,Second|Rest] = [1,2,3]

Slide 46

Slide 46 text

Underscore Variable ● Can be used in place of a regular variable in a pattern ● No values are bound to it, meaning it can match any value anytime it is used ● It’s common to use it if we don’t care about a value in a pattern {_, _} = {1,1} {_, _} = {1,2} {Num, Num} = {1,2} % ** exception error: no match of right hand side value {1,2}

Slide 47

Slide 47 text

Pattern Matching in Functions ● Function clauses use pattern matching to determine which clause should be executed % add/2 has three clauses add(0, 0) -> 0; add(X, X) -> X * 2; add(X, Y) -> X + Y.

Slide 48

Slide 48 text

Recursion

Slide 49

Slide 49 text

Recursion ● Recursive functions are functions that call themselves ● Recursive functions are used when repetition is needed ● If a function calls itself and never returns an infinite loop is created ● Tail call and other optimizations so you never run out of stack space

Slide 50

Slide 50 text

Recursion sum_list(List) -> sum_list(List, 0). sum_list([], Acc) -> Acc; sum_list([Head|Tail], Acc) -> sum_list(Tail, Acc + Head).

Slide 51

Slide 51 text

Processes

Slide 52

Slide 52 text

Process Messaging % `Pid` is a process ID Pid ! {add, 1, 2, self()} % Receive a message in the process receive {add, X, Y, Caller} -> % Send the result back Caller ! add(X, Y) _ -> error end

Slide 53

Slide 53 text

Spawning a Process ● Processes will return until the function they are running ends or encounters an exception ● Recursive functions are typically used for servers % Assuming ?MODULE:math_server/0 is a function {ok, Pid} = spawn(?MODULE, math_server, []).

Slide 54

Slide 54 text

Math Server Demo • API for the caller • API calls send messages to the server, which does the arithmetic • Result is sent back to the client process via a message, which then causes the original call to return with the result • With and without OTP supervision

Slide 55

Slide 55 text

Math Server Demo <0.97.0> Math Server <0.59.0> Shell Process (Us) <0.83.0> start {add, 1, 2} {response, 3}

Slide 56

Slide 56 text

Demo

Slide 57

Slide 57 text

Conclusion

Slide 58

Slide 58 text

Conclusion ● Fault tolerance is at the center of Erlang’s design ● Erlang gives us the constructs we need to build concurrent applications ● OTP gives us the tools we need to build fault tolerant applications in Erlang ● Erlang’s concurrency model enables Erlang to support things like distribution and hot code upgrades ● Erlang is an ideal choice if you want a language that can scale with your company

Slide 59

Slide 59 text

Things I Didn’t Cover ● OTP behaviors ● Metaprogramming ● List comprehensions ● Type checking with Dialyzer ● And much more...

Slide 60

Slide 60 text

Resources ● Official Website - http://www.erlang.org/ ● Online REPL - http://www.tryerlang.org/ ● Free Book on Erlang - http://learnyousomeerlang.com/ ● Programming Erlang Book - https://pragprog.com/book/jaerlang2/programming-erlang

Slide 61

Slide 61 text

Trevor Brown @Stratus3D Github.com/Stratus3D stratus3d.com [email protected] https://github.com/Stratus3D/why_erlang