• Electric Clojure
  • a distributed and reactive programming language
  • define a distributed program (i.e. unified client/server program) in Clojure
  • targets full compatibility with Clojure/Script
    • means you can copy/paste a Clojure expression into an Electric expression and the expression will evaluate to the same result
• Clojure/Script hosts Electric Clojure/Script programs
  • Electric is a Clojure/Script library
  • Electric programs are defined in Clojure code files (.cljc, .clj, .cljs)
• Electric Server = websocket server for Electric clients
  • Today supports Jetty 9 and Jetty 10
  • ring-compatible
• Electric Compiler = a Clojure -> "Electric bytecode" compiler
  • implemented as an ordinary Clojure macro
  • implements clojure/script compiler & analyzer infrastructure for full compatibility with Clojure, including all special forms
• Electric bytecode = "graph bytecode" for a distributed & reactive program
• Electric VM = a distributed & reactive VM
  • The VM models a computation spread across N concurrent sites (today N=2 - backend/frontend), with managed state sync.
  • Managed network means the concrete distributed program matches the semantics of the intended abstract program as defined the source code, regardless of where the actual computation happens or how the state got synced.
• Network planner = the part of the VM that finds the optimal cut
  • operates on IR
    • This is the same as Java: there are optimizations performed by the compiler and also the runtime.
    • compare to Postgresql as a query planner to choose the fastest query
    • Electric has a network planner to choose the optimal network transfers
  • we currently believe there is always a perfect solution with zero superflous transfers; i.e., any time a perfect compiler plans a round trip, it is because the program as written cannot be expressed without it.
  • today the cut is computed at compile time, but will be runtime in the future
    • the compiler doesn't know everything; this is the main source of superfluous round trips today
      • dynamic linking - virtual methods - this is how lambdas work
  • today, we focus on correct language semantics over optimal network topology. Now that we are useful in production, we will use production learnings to implement a planner that optimizes for real world conditions.
    • it is already quite good in practice
    • the demo of virtual scroll over node_modules streams thousands of records between client/server as you drag the scrollbar, it feels great
• Electric Site Runtime
  • Platform target sites (brower, server) that participate in the distributed VM
• Missionary Reactor
  • FRP engine with glitch-free propagation
  • holds the actual runtime state of each site process
    • server state, one reactor per websocket session
    • client state, one reactor in the browser
  • Java, JS implementations
• JVM/Browser/Node