problem description

• multiple teams will work on the codebase. integration tests must occur later.
  • corollary: build and debugging tooling must be robust, and reach target scale
  • one example: compile times shouldn’t increase exponentially over the size of the code

problem description pt. 2

• the telephone switching code will be deployed into physical hardware
• hardware will be physically deployed in many remote locations

problem description pt. 3

• both deployment and later on site maintenance is very costly
• it is expected that software cannot be proven correct in advance of deployment
• the software should be able to continue operating despite defects inside itself

solution part 1: let it crash

• Erlang's architecture is based on the observation that most software defects are resolved with a reset
• Create software that has the capability to reset it’s own modules when errors are detected in those modules

• it's more fun than it sounds

solution part 2: aggressively abstract away platform

• Erlang's designers don’t know what hardware architecture will be used
• Erlang's designers know the performance characteristics of the platform
  • number or size of cpus, memory, disk, network interfaces

two assumptions this argument makes about your problem

• the profitability of your enterprise is limited primarily by the architectural approach of the technology in use

• you have experienced one or more of these problems in production:

  • your software is not performant
  • it's difficult to reason about whether or not the code you write will be performant
  • your apps do not scale across cores and servers like you think they need to

Regardless of your problem, I'll make the argument that:

• platforms that you will eventually use will have adopted many of these concepts
• Erlang's history is a good study in how to effectively evolve an architecture fit for purpose

the runtime

glossary

let's drink a tall glass of the kool aid

• process === fine grained task
• concurrency vs parallelism
• soft real time

glossary, pt. 2

• beam = Bogdan/Björn's Erlang Abstract Machine
  • the defacto Erlang virtual machine implementation
• erlang = a programming language with a compiler to bytecode run by the beam
• elixir = a programming language with a compiler to bytecode run by the beam
• erts (erlang runtime system) = the erlang distribution. erlang + beam + standard libraries + otp
• OTP = the portion of the libraries included with distributions specifically intended for creating concurrent, highly available, soft real time systems

features

• functional, but not purely functional
• actor concurrency model enforced
  • anti-feature: you can’t not use it
• sophisticated pre-emption of concurrent tasks
• shared nothing memory

elixir

elixir's compiler

• elixir code will become beam bytecode
• relaxed, ruby-like syntax (parentheses optional on function calls)

elixir's compiler: example

defmodule Hello.Demo do
  IO.puts "Hello, World!"
end
Hello, World!
{:module, Hello.Demo,
<<70, 79, 82, 49, 0, 0, 3, 152, 66, 69, 65, 77, 69, 120, 68, 99, 0, 0, 0, 60, 131, 104, 2, 100, 0, 14, 101, 108, 105, 120, 105, 114, 95, 100, 111, 99, 115, 95, 118, 49, 108, 0, 0, 0, 2, 104, 2, ...>>,
:ok}

• define an Erlang module
• compile it to bytecode
• return that bytecode back to my interactive shell
• load that bytecode into my beam vm
• run code inside the block
• in doing so send a message "Hello World!" to the default IO sink, which is another Erlang process

elixir's tooling

• mix, for projects
  • uses a single project definition file
  • fetch dependencies using git, build documentation, create release packages, generate OTP compilant application boilerplate, and more
  • transitive dependency management
• hex
  • rubygems / cheese shop for elixir
• documention: python inspired features are now standard issue
  • docstrings, doctests

elixir's features

• hygienic macros + hygienic macros + more hygienic macros
• erlang typespecs still work, for dialyzer’s bytecode mode
• right association inside data structures are represented using Elixir's Stream
  • takes you down the path toward lazy evaluation

elixir's features, pt. 2

• "protocols" provide polymorphism
  • they're not generics - those are a runtime thing, instead it's templates + metaprogramming
  • if you refer to a protocol by name, the elixir compiler will rewrite your code

elixir's features, pt. 3

• "sigils" provide an extensible way to do string interpolation

# A regular expression that returns true if the text has foo or bar
iex> regex = ~r/foo|bar/
~r/foo|bar/
iex> "foo" =~ regex
true
iex> "bat" =~ regex
false

what? isn't that a little too much information???

the features elixir brings are for software library authors.

after a sufficient number of libraries are published, this is good for everybody