Go vs. Elixir for distributed computing

Go and Elixir are great tools for modern distributed computing.
People tend to compare BEAM's capabilities with Kubernetes's on that matter.

2. Purpose - Open/contribute to the conversation towards better distributed systems. - NOT a language comparison where only one can win - NOT a benchmark comparison - NOT a contest or a roast.
3. Purpose - Also: won’t do a symmetrical assessment, instead, I will tell you my favorite things, technical and non-technical from both approaches - I find these more useful at decision making times
4. Why Distributed Systems?
6. Why - Personal passion project - Went to school for that - Used to be a scientist; it’s still an area that works closely with research (when people listen) - Multiple implementations: the same goal - It has a lot of maths, if you want to
7. Why - Multiple implementations: the same goal - Better systems for everyone (democratic: more power to the algorithms vs. shiny stuff) - Many (productive!) ways to represent them and study them (math, graph theory, topology, code)
8. Go “vs." Elixir
9. Elixir • Actors, as the universal primitives of concurrent computation • Inspired by physical laws • Influenced by Lisp, Smalltalk • Functional (better syntax thank Erlang) • BEAM VM
10. In response to messages, Actors con concurrently: 1. Send a finite number of messages to other Actors 2. Create a finite number of new Actors 3. Designate the behavior to be used for the next message it receives
11. Actor model: my 2 favorite things • Modularity through direct communication and asynchrony • Indeterminacy and Quasi-commutativity
13. Modularity through direct communication and asynchrony - One-way asynchronous communication - Once a message has been sent, it is the responsibility of the receiver - Messages decoupled from the sender
14. Indeterminacy and Quasi-commutativity - Like in math, in systems, the arrival order of messages can affect future behavior - Quasi-commutativity is used to tame indeterminacy
15. But there’s more: fault tolerance <3 (BEAM’s jewel in the crown)
16. Fault Tolerance • Built-in: strong isolation between concurrent processes • Go: “it depends on the use case”. LOL
17. The Go Programming Language
18. Go • So easy to use! • Stdlib • Easy to read • Learning curve • Insert personal story here (this changes everything!)
19. But also: Kubernetes (and containers in general) <3 (Go’s distsys jewel in the crown)
20. Why mentioning Kubernetes? (in this context) • It is the go-to resource for distributing a system used by Go developers • Teams that already use containers, look at it as a natural next step • But also...
21. Why (mentioning) Kubernetes? In the subset of practical (non-academic) distributed systems, people often compare Kubernetes’ capabilities with the BEAM’s, usually to dismiss each other. It’s worth mentioning that you can have both <3
22. One last thing: testing distributed systems
23. Testing distributed systems 1. A whole new beast, where the 100% coverage of unit tests is the least of our concerns 2. Having a container-based approach for tests helps a lot 3. Testing in production: 4. Property-based testing: Fred Hebert
24. Conclusions