A Brief Introduction to Erlang

A short high level overview of the Erlang programming language, with a brief look at OTP applications.

Transcript

1. Introducing Erlang A Brief Survey of The Erlang Programming Language Rebecca Skinner April 8, 2018 Rackspace Hosting 1
2. 1 What is Erlang? 2
3. Erlang is Weird • strong, dynamic typing • Pure functional • Syntax influenced by prolog, lisp, and smalltalk • Compiled to BEAM 3
4. The Beam Beam is name for erlang’s virtual machine. Erlang code compiles to beam bytecode. The beam provides process and thread management, as well as networking and IPC across distributed processes. 4
5. Beam Languages • Elixer: a beam language with syntax superficially resembling ruby, because ruby • LFE: A lisp for the beam, because (((even (lisp is) ’better) than) (erlang syntax)) • Idris: a dependently typed ML written in haskell • Purescript: more-or-less haskell, but for javascript (and the beam too, I guess) • Elm (eventually?): megablock training wheels version of purescript. They keep talking about eventually targetting beam in addition to javascript. 5
6. OTP The Open Telecom Platform (OTP) is a set of libraries and middleware to facilitate writing distributed stateful appliations. OTP facilitates the development of highly scalable, fault tolerant applications. 6
7. 2 Introducing Erlang 7
8. Hello, Erlang −module( hello ) . −export ( [ hello_name /1 ] ) . hello_name (Name) −> io : format ( " hello , ~p \ n" , [Name] ) . 8
9. Modules There is a 1:1 relationship between erlang files and modules. Each module defines it’s name using the -module preprocessor directive, and declares all exported functions with the -export directive. Erlang modules act as namespaces. When calling a function from another module, or a REPL, the module name should be prefixed to the function name. hello : hello_name ( " World " ) . 9
10. Variables Erlang variables are immutable and statically typed. All erlang variables start with a capital letter. Erlang variables can have any of the following types, which are assigned at runtime: • integers • floats • atoms • binary strings • references • functions • ports • processes • tuples • maps • lists • strings • records • booleans 10
11. Terms The fundamental type in erlang is the term. A term is the fundamental representation of a value in erlang. 11
12. Atoms An erlang atom is similar to a symol in lisp or ruby. Atoms can be used just like you might use an enum or named constant in another language. Erlang uses atoms to name records, and they can also be used to identify processes or messages. 12
13. Lists Lists in erlang are 1-indexed heterogenous collections of terms. Erlang lists are constructed of cons cells. As a matter of convenience, an erlang list may be constructed as a sequence of terms without specifying the cons cells. A list shown with explicit cons cells is known as it’s canonical representation. 13
14. List Examples > % % integer , string , atom > List1 = [ 1 , " two " , three ] . [ 1 , " two " , three ] > % % get the f i r s t element from the l i s t > l i s t s : nth ( List1 , 1 ) . 1. > List1 == [ 1 | " two " | [ three | [ ] ] ] . true 14
15. Strings and Characters Erlang does not differentiate between integer values and characters. All characters are stored as integers representing the UTF8 codepoint of the character. A string is an integer list of codepoints. Character literals can be written by prefixing the characteer with the $ symbol. [ $h , $e , $l , $l , $o ] . " hello " $a . 97 15
16. Bit Strings Erlang has special syntax for dealing with packed binary data. This feature makes it particularly suited for dealing with low level network protocols. A bit string is a packed binary representation of a list of binary values. Lists of integers can be passed into a bit string to be packed into their binary representation. Like with lists, the $ symbol can be used to insert the numeric value of a character literal. 16
17. Bit Strings Cont. When creating a bit string, there are several options that can be provided to specify in detail how the binary value will be packed. The general format for a field in a bit string is: Value:Size/Type-Specifier-List Where Size is the number of bits used the represent the value, and Type-Specifier-List is a hyphen separated list of options. 17
18. Type Specifier Description type The type of the term. Must be one of: integer, float, binary, bytes, bitstring, bits, utf8, utf16, utf32 endianness The endianness of the value: Must be one of big, little, native unit The unit size of a binary value. Fields will be stored in size∗unit bit sets, and unsized fields will be aligned to Unit bits. Signedness Whether or not the value should be consid- ered signed (for pattern matching). Must be one of signed, unsigned 18
19. Bit String Examples IPHeader = <<Version : 4 , 5/ integer−u n i t :4 ,DSCP:6 , ECN:2 , Len :16/ big , Ident :16 ,0/ integer−u n i t :1 , DF/ integer−u n i t :1 ,MF/ integer−u n i t :1 , FO:24 , TTL , Proto , Checksum:16 , SourceIP :32/ big , DestIP :32/ big >> 19
20. Pattern Matching Erlang supports pattern matching of variables. Record and tuple fields, list elements, and fields from bit strings can all be pattern matched. [A, B, 3 ] = [ 1 , 2 , 3 ] . { foo , Bar } = { foo , bar } . 20
21. Functions Functions in erlang are pure. They may accept any number of arguments, and always return exactly one value. The return value of an erlang function is the value of the last statement in it’s expression. Statements within a function are separated by commas, and a function is terminated with a period. 21
22. Basic Function Example show_addition (A, B) −> Sum = A + B, {A, B, Sum} . 22
23. Function Arity The arity of the function is the number of arguments the function accepts as input. In Erlang, the arity of a function is part of the fully qualified name of that function. The arity of a function may be omitted when calling the function, otherwise arity of a function is specified by a forward slash and the arity. Erlang functions are not polymorphic over the number of arguments per-se, but due to the fact that the arity of the function is part of the functions canonical name, functions of different arities may share a name. 23
24. Function Arity Example add (A,B) −> A + B. add (A,B,C) −> A + B + C. get_add_function ( Count ) −> case Count of Count = 2 −> fun add / 2 ; Count = 3 −> fun add / 3 ; _ −> { error , " i n v a l i d count " } end . 24
25. First Class Functions Erlang functions can be passed around as regular values. They can be stored in lists, maps, and records, passed in and returned from functions, and sent as messages to other processes. The fun keyword is used to refer to a function value. 25
26. Another Function Example foldFunc ( Elem , Carry ) −> BindFunction = monad : bind (maybe_m: maybe_monad ( ) ) , BindFunction ( Carry , fun ( BareCarry ) −> BindFunction ( Elem , fun ( BareElem ) −> maybe_sum( BareCarry , BareElem ) end ) end 26
27. Guards and Pattern Matches. A function can specify limits to the input values it operates on. Pattern matching may be used to limit the input values of a function at a structural level. Erlang supports unification of pattern matched values, allowing for equality comparisions along with destructuring. In addition to pattern matching where statement creates a guard that allows a developer to specify a set of contraints on the values of function parameters, including the values of variables assigned to destructured elements of an input value. Piecewise functions differentiated by pattern matching and guards should be separated by semicolons. 27
28. Pattern Matching Example l i s t s _ e q ( [ ] , [ ] ) −> true ; l i s t s _ e q ( [X|XS] , [X|YS] ) −> l i s t s _ e q (XS,YS) ; l i s t s _ e q (_ , _ ) −> false . Note how, in this example, the same variable, X is used to represent the head of both lists. Thanks to unification this pattern match allows us to assert equivalence over the values at the head of each list, leading to a very terse method for comparing 28
29. Guard Examples f i b (X) when (X =< 1) −> 1; f i b (X) −> f i b (X − 1) + f i b (X − 2 ) . 29
30. Tuples Erlang suports heterogenous tuples of arbitrary size. Erlang uses braces to reprsent tuples. Elements of a tuple may be accessed through destructuring. {tuple1, tuple2, tuple3} 30
31. Maps Erlang maps are sets of key/value associations. The # symbol is used to define a map. Keys in an erlang map may be any term, including functions, processes, maps, or, most commonly, atoms. mapTest ( ) −> F = fun ( ) −> 1 end , {F , #{F => foo , foo => bar } } . 31
32. Destructuring Maps Maps may be destructured using the := operator. A destructured map over a pattern must contain at least the specified elements, but the pattern need not include every element of the map. mapTest(# { foo := Value , const := const } ) −> Value . % okay , has keys foo and const demo: mapTest(# { bar => bar , foo => foo , const => const } ) . % not okay , no key ’ const ’ demo: mapTest(# { bar => bar , foo => foo , c => const } ) . 32
33. Updating Maps Like all values in erlang, maps are immutable. Erlang provides some syntactic sugar to make it easier to add and update values in maps. mapTest ( ) −> M = #{ foo => foo } , WithBar = M#{ bar => bar } , Updated = WithBar#{ foo := foo1 } , Updated#{ baz => baz } . mapTest ( ) . % #{ bar => bar , baz => baz , foo => foo1 } 33
34. Records In addition to maps, erlang supports record types. Records behave in many ways like a map, but specify a fixed set of key values that are associated with a name. Records are defined with the preprocessor directive -record. −record ( state , { offset , l i s t } ) . 34
35. Defining a Record A record is defined with a name and a set of field names with optional default values. When a new record is created, any keys without a default value that are not set will be undefined. Records cannot be exported from a module. Due to this limitation, it is common to define records in header files with the .hrl extension. These records are then imported to provide record definitions across modules. −include ( " myrecords . h r l " ) . Figure 1: module.erl −record ( foo , {a , b , c=3} ) . Figure 2: myrecords.hrl 35
36. Creating and Updating Records To create a record value you must supply the name of the record, and values for any of the keys you want to set. Like with maps, you can update a record by specifying the record, followed by the name and any new or changed key/value pairs. Foo = #foo {a = "a" , b = "b" } . % #foo { "a " , " b" ,3 } . Foo1 = Foo#foo { c = 0} . % #foo { "a " , " b" ,0 } . 36
37. Accessing Record Elements Foo = #foo {a = "a" , b = "b" } . Foo#foo . a . % get f i e l d a from the record % "a" 37
38. Pattern Matching Records Records can be pattern matched in the same way as maps, with the addition of the record name. As with maps, not all record fields are required for a pattern match, and unification allows pattern matches to assert equality of separate record fields. recTest (# foo {b = B, c = B} ) −> same ; recTest (# foo {b = B, c = C} ) −> {B, C} . 38
39. 3 OTP 39
40. What is OTP? The Open Telecom Platform (OTP) is a set of libraries, middleware, and tools designed to assist in building distributed fault tolerant applications. OTP is part of the erlang distribution and runtime, but can be used with other Beam languages such as Elixer. 40
41. OTP Architecture OTP prescribes an architecture that lends itself particularly well to fault tolerant distributed applications, and plays to the particular strengths of ther Beam and erlang as a language. OTP is built around the concept of message passing, actors, and supervision trees. 41
42. Behaviors Erlang behaviors are, essentially, a module level interface. A behavior defines a set of required functions and their arity. OTP defines several behaviors that are important for the OTP Architecture. 42
43. OTP Behaviors Behavior Description supervisor Monitors workers and other supervisors supervisor_bridge Supervises non-OTP applications gen_server A generic server gen_fsm A generic finite state machine gen_event A generic event handler gen_statem A generic state machine 43
44. Supervisors A supervisor is one of the most common types of OTP application processes. Supervisors are simple applications whose job is manage the lifecycle of 44
45. Sample Supervisor s t a r t _ l i n k ( ) −> supervisor : s t a r t _ l i n k ( { local , ?SERVER} , ?MODULE, [ ] ) i n i t ( [ ] ) −> SupFlags = #{ strategy => one_for_one , i n t e n s i t y => 1 , period => 5} , AChild = #{ id => ’AName ’ , s t a r t => { ’ AModule ’ , s t a r t _ l i n k , [ ] } , r e s t a r t => permanent , shutdown => 5000, type => worker , modules => [ ’ AModule ’ ] } , {ok , { SupFlags , [ AChild ] } } . 45
46. Supervisor Restart Strategies strategy description one_for_one if a child process terminates, restart it one_for_all if a child process terminates, termi- nate all other children then restart them all rest_for_one if a child process terminates, all pro- cesses started after the child are also terminated, then all terminated pro- cesses are restarted simple_one_for_one a variant of one_for_one where all child processes are dynamically cre- ated instances of a single process 46
47. Supervision Trees Supervisors may supervisor worker processes and other supervisors. The architecture of an OTP application will begin resembling a tree, where interior nodes are supervisors, and leaf nodes are sets of related processes. Understanding the supervision tree of an application is often the first step to being able to understand, modify, or debug the application as a whole. 47
48. Generic Servers s t a r t _ l i n k ( ) −> gen_server : s t a r t _ l i n k ( { local , ?SERVER} , ?MODULE, [ ] , [ ] ) . i n i t ( [ ] ) −> process_flag ( trap_exit , true ) , {ok , # state { } } . handle_call ( _Request , _From , State ) −> Reply = ok , { reply , Reply , State } . handle_cast ( _Request , State ) −> { noreply , State } . handle_info ( _Info , State ) −> { noreply , State } . terminate ( _Reason , _State ) −> ok . code_change ( _OldVsn , State , _Extra ) −> {ok , State } . format_status ( _Opt , Status ) −> Status . 48
49. Generic Servers OTP Generic Servers (gen_servers, or genservers) are where most computations take place in an OTP application. A genserver is a process that manages discrete state changes and answers various types of requests. Several functions are defined by the genserver behavior, but we’ll look briefly at the most important functions. 49
50. Genserver Functions Function Description init Creates the initial state of the applica- tion, like a constructor handle_call Takes a request and a state, returns a reply and a new state handle_cast Takes a request and a state, updates state without replying start_link Initialize the OTP process 50
51. Another Genserver Demo −record ( state , { offset , l i s t } ) . i n i t ( [ ] ) −> {ok , # state { o f f s e t =0 , l i s t =[ ] } } . handle_call ( { update , L i s t } , _ , State ) −> { reply , List , State# state { l i s t = L i s t } } ; handle_call ( get_word , _ , # state { o f f s e t =Offset , l i s t = L i s t NewOffset = ( Offset + 1) rem length ( L i s t ) , Elem = l i s t s : nth ( Offset + 1 , L i s t ) , { reply , Elem , # state { o f f s e t =NewOffset , l i s t = L i s t } } ; handle_call ( g e t _ l i s t , _ , State ) −> { reply , State# state . l i s t , State } . 51
52. The Genserver Update Loop The genserver update loop is how OTP applications manage stateful processes within a pure immutable functional language. For all key genserver functions, the previous application state is passed in as an explicit function parameter. Any state changes are made during the process of running the application, and a new state is returned. OTP and the erlang runtime manage this state, between calls. Because all erlang values and variables are immutable, there is no concern of any references within a genserver’s state being changed during execution. 52
53. 4 Tooling 53
54. Kerl kerl is a utility that allows you to manage installations of erlang. Kerl will compile and install local versions of erlang, and provides bash scripts to allow you to activate and deactivate environments to use each version. Kerl also allows you to install a per-project OTP distribution. 54
55. Rebar3 rebar3 is a tool to allow you to manage packages and build erlang applications. Rebar3 expects conventional OTP structured applications, and provides tools to build and package erlang applications with their runtime. 55
56. Dialyzer dialyzer is an optional success typing system that allows you to perform rudimentary static analysis of erlang applications. Dialyzer is based on published research that investigated concrete real world applications for gradual success typing to improve the reliability of applications written in dynamically typed languages. 56
57. Observer Observer provides debugging and observability to erlang applications. Observer allows you to connect to remote beam instances, view individual process mailboxes, send messages, delete messages, visualize the supervisor tree, and to kill and restart supervisors and worker processes. 57
58. 5 Questions? 58