Tweet
Tweet

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

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.

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Why Distributed Systems?

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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)

Slide 8

Slide 8 text

Go “vs." Elixir

Slide 9

Slide 9 text

Elixir ● Actors, as the universal primitives of concurrent computation ● Inspired by physical laws ● Influenced by Lisp, Smalltalk ● Functional (better syntax thank Erlang) ● BEAM VM

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Actor model: my 2 favorite things ● Modularity through direct communication and asynchrony ● Indeterminacy and Quasi-commutativity

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

But there’s more: fault tolerance <3 (BEAM’s jewel in the crown)

Slide 16

Slide 16 text

Fault Tolerance ● Built-in: strong isolation between concurrent processes ● Go: “it depends on the use case”. LOL

Slide 17

Slide 17 text

The Go Programming Language

Slide 18

Slide 18 text

Go ● So easy to use! ● Stdlib ● Easy to read ● Learning curve ● Insert personal story here (this changes everything!)

Slide 19

Slide 19 text

But also: Kubernetes (and containers in general) <3 (Go’s distsys jewel in the crown)

Slide 20

Slide 20 text

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...

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

One last thing: testing distributed systems

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Conclusions

Slide 25

Slide 25 text

No content