gistfile1.txt

elixir stuff

talk about actor model
- run in their own process
- have a message inbox
- send messages to it, it does work, and then it replies with the result
- sound like an OO object?
- state is hidden from outside world
- each actor handles one message at a time (isolation)
- concurrency by spinning up LOTS of actors that send messages to each other
- run as many processes in parallel as you have cores
- actor will be preempted on I/O or too much CPU, so that’s how you get concurrency

distribution
 - erlang has 1st class support for communicating with processes across machines
 - a “cluster” is made up of multiple machines
 - processes are distributed across them
 - transparent to application where processes are running 

exceptions
  - remember that node philosophy of letting it crash?
  - erlang/elixir are the same!
  - except, you restart an erlang process, not the entire server
  - one process can’t bring down another unless explicitly linked

negatives:
  - not terribly fast at running any one process
  - smaller community
  - different way of organizing applications

Sample application:
  - used TTM’s live teaching application as inspiration
  - started rewriting the entire node application for this talk, but it was too big
  - pared it down to two apps that simulate students and teachers sending messages to each other
     - students connect and go into a queue
     - teachers can talk to up to 5 students at a time
     - teachers and students exchange 50 messages each
     - then the teacher ends the session
  - how fast can we service all the students in the queue?
  - as an aside, if you are building a real-time application this kind of stress test is guaranteed to identify lots of race conditions between client and server.
    - for example, a student joining, subscribing to events, but teacher fired events before the server  acknowledged the subscription

Architecture of application:
  - Express, node 0.10.34, faye 1.0
    - used faye because that’s what we use at TTM
    - experimented with socket.io as well

  - Erlang 17, Elixir 1.0.2, Phoenix 0.8-dev (master)

  - node client to act as students/teachers
     - different adapters for faye/phoenix WebSocket API
     - Can run students/teachers in same process or in separate processes

Basic sequence diagram:

   - Teacher and students connect to a “presence” channel
   - Teacher tries to add a student as long as they have room
   - If a student is available, both are sent a message to join a private chat room
   - when both have joined room, teacher sends the first message
   - Teacher and student ping/pong messages until each has sent 50 
   - Teacher terminates the chat
   - Student disconnects
   - Teacher tries to grab another student

Look at some code!
  - Phoenix
   - Student Roster module
     - Basic elixir modules
     - immutable, show how one would use it in IEX
   - Show Student Roster Server module
     - Explain that this is making an actor
     - Explain call vs. cast
     - Show subset of boilerplate version
     - Show ExActor version
        - could never do that in Erlang. Elixir makes this kind of metaprogramming possible.
   - Show Channels
     - Pattern matching

  - Node
    - Show “Channels”
    - Show “models”
    - Explain drawbacks
     

NOTES:

have to think in moregi coarse APIs
use exactor to get rid of boilerplate

10 teachers, 1000 students, 100 messages per chat (50 student, 50 teacher):
node: (1 core): 41s
node: (split teacher and student)): 41s
jelixir: (all cores) 31s
elixir: (all cores, split teacher and student) 22
elixir (1 core): 58s
elixir (1 core, split): 51s

remote:
elixir:
both on client: 1m21
teacher on server: 41
student on server: 46

node:
both on client: 1m46
teacher on server: 1m17
student on server: 1m44