Why time is evil in distributed systems

Interesting presentation about distributed systems:

Peter does a good job a simplifying the programming task down to two categories:

  1. stuff that can be implemented in pure functions
  2. stuff that has uncertainties (interaction points) that must be implemented using imperative methods

This is a helpful framework for thinking about programming.

A few more notes:

  • functional programming is powerful, but it can’t interact with the real world
  • write most of the program in functional programming, and add small pieces of imperative programming only in those places that interact with the real world
  • Lamda calculus
    • final result of a reduction is the same for all reduction orders
  • keep mostly pure with a few interaction points
  • examples of interaction points
    • mutable state
    • non-determinism where you wait for several things
    • failure
  • Eventual consistency database replica example
    • Removing interaction points
    • eventual consistency, several ways
      • use strong consistency (quorums). Give up performance
      • use convergent consistency (CRDTs)
        • use monotonic writes instead of arbitrary writes
        • add information – order does matter
    • convergent consistency
      • reads observe previous writes
      • successive reads observe increasing set of writes
      • writes applied after observed reads
      • better then eventual consistency
  • Principles of Eventual Consistency by Sebastian Burckhardt (highly recommended book)

Elm seems to do a good job following these principles – interaction points with the real world (http, ports, etc) are very controlled and kept to a minimum.