Modeling the real world with Elixir/OTP at QCon New York 2018

This is a forty minute talk that I gave at QCon New York in 2018.
I talked about how my employer PagerDuty started to use Elixir, and talked on some attributes of the language and what made it a good fit for modeling a natural phenomenon. Towards the end of this talk I gave a demo of a text based Boids simulation (https://github.com/aishraj/boids)

Transcript

1. Modeling the real world with Elixir and OTP Aish Raj Dahal
2. Why are we here? • Concurrency, Events and the Real World • Case study of an Elixir use • Tour of the BEAM and OTP • Demo time!
3. How did we get here ? Epilogue
5. “Can programming be liberated from the von Neumann style” ?
6. Elixir is a programming language that leverages the power of Erlang VM (BEAM)
7. With a simple syntax and a supportive community the language has seen tremendous growth
8. A lot* of PagerDuty is powered by Elixir
9. It has always not been this way.
10. At PagerDuty it started as a language of choice for Rails- native way to talk to Kafka
11. Why ?
12. It was high value
13. It was easy to redo it in a different language
14. How was it ?
15. It was not all rainbows and unicorns
16. The application needed some tuning
17. But language never got in the way
18. Since then...
19. A cambrian explosion in Elixir based services
20. A good number of critical backend applications are written in Elixir
21. All with the niceness of being built for the Real- World ™
22. The Real World Chapter I
23. What is the Real World™?
24. Are we talking about the universe ?
25. In the beginning the universe was created. This has made a lot of people very angry and been widely regarded as a bad move. Douglas Adams, The Hitchhiker’s guide to the Galaxy
26. The Real World ™ is the world we live in
27. You must care about it because….
28. When was the last time you programmed a non- multi-core computer ?
29. Computer science is no more about computers than astronomy is about telescopes. Edsger Dijkstra
30. Software you write probably models a real world situation
31. Software you write probably deals with events
32. Mental model of the real world:
33. It is inherently concurrent
34. It is event-based
35. Failures are unpredictable
36. It tends to be “real time”
37. Software you write for the Real World ™ should deal with these situations.
38. Which means...
39. Your software should be concurrent.
40. Your software should deal with events
42. Your software should be fault- tolerant.
43. Your software should respond to the user-input within a reasonable* time.
44. Erlang solved these problems around three decades ago
45. But this talk is not really about the Erlang programming language
46. A Whirlwind tour of Elixir, BEAM and OTP Chapter II
47. Key ideas in Elixir
48. Isolated Processes
50. Pure Message Passing between processes
52. The ability to detect errors in remote processes
53. A method for determining what error caused a process to crash
55. This means that Elixir is • Concurrent
56. This means that Elixir is • Concurrent • Fault tolerant
57. This means that Elixir is • Concurrent • Fault tolerant • Soft real time
58. And built in support for things like hot code swap
59. Detour: Open Telecom Platform (OTP)
60. OTP is a set of libraries and tools that provides fundamental abstractions for BEAM languages
61. Here are some nice building blocks that OTP provides
62. GenServer: A generic server
64. Process Supervisors
66. Agents: State Wrappers
68. Sounds like what you will want for the Real World ™
69. Demo time Chapter III
70. Boids
71. The rules of flight
72. Separation: Steer to avoid crowding local flockmates
73. Rule I: Separation
74. Alignment: Steer towards the average heading of local flockmates
75. Rule II: Alignment
76. Cohesion: Steer to move toward the average position (center of mass) of local flockmates
77. Rule III: Cohesion
78. Modeling this with Elixir/OTP
80. Modeling the events
81. Move
82. Render
83. Dealing with failures
84. Restart the boid
85. Concurrency
86. Keep your processes light and have many of them.
87. Epilogue
88. Make it work, then make it beautiful, then if you really, really have to, make it fast. Joe Armstrong
89. - @aishrajdahal