«

ElixirConf US 2015 notes

ElixirConf US 2015 was October 2–3 in Austin, Texas.

Bruce Tate: The Pendulum

tech swings back and forth between approaches to problems. batch vs interactive…​

  • request/response not quite enough…​ appearance of MVC pattern for local software

    • GUIs…​

  • scaling on the web follows the same pattern

    • concurrency/isolation are key for future…​

      • elixir!

Chris McCord: What’s Next for Phoenix

  • Phoenix beyond browser: Channel clients in JS, Swift, ObjC, C#, Java…​

  • planned for v1.1: gettext, Channel presence

    • gettext internationalization was meant for 1.0, but was trickier than expected

    • channel presence is very much non-trivial on distributed nodes

  • look at GraphQL for ideas

    • support in views? so instead of having to e.g. preload: [user: [:profile]] etc when fetching stuff in your controller

    • can help avoid "controller mayhem" (proliferation of routes for specific data shapes, versioning)

    • specs are defined in the clients, not server…​

      • but the server will still do validations, deprecations?

    • "server side views as just another GraphQL client"

      • js clients as well as backend template construction could both use it

      • way way down the line, maybe "virtual DOM on the server"

    • why not extend Ecto to do this sort of thing? not out of the question.

Paul Shoenfelder: Release Management with ExRM and Conform

  • OTP apps: well-defined structure, explicit dependencies, useful metadata

  • non-release way: dev deps in prod, can’t manage multiple apps, need to build things, can’t cross-compile…​

  • what’s a release? versioned OTP app dependencies; ERTS; release metadata; configuration; scripts to manage; packaged as tarball

  • what’s ExRM? extends Relx (Erlang’s release tool); provides mix tasks (with lots of hooks), appup generation, intelligent defaults

  • configuration is compiled into static info in release (e.g. no dynamic config, can’t use get_env)

  • schema allows for data transformations (and validations?)

Alexander Songe: CRDTs: Datatypes for the Apocalypse

"conflict-free datatype"…​ how to have distributed complex values

  • CRDTs are tricky; not many usable libraries

    • not a lot of code, but it has to be precise or you’ll corrupt source data

    • need to test a lot, 100% code coverage doesn’t count, need to find edge cases

  • basis:

    • log-based: read over logs, replay things

    • state-based: easier to reason about, but get big (& therefore hard to manage)

  • updates to mutate state

    • updates are commutative, associative, idempotent

    • …​& therefore can be sent over network, will be eventually consistent

      • as long as everyone eventually communicates

  • types:

    • flags, counters, sets, registers, maps, graphs, documents (huge…​)

  • examples

    • G-counter: counts up only. distributes values but takes max, so ensures eventually consistent. (can’t decrement…​ have another G-counter for decrements.)

    • G-set: adds items to a set. similar problem for subtracting; solved with ORSWOT operation.

      • (similar but not quite the same as a vector clock)

  • wider use of CRDTs…​ not so much

    • would be super useful in rich clients

    • Loom

  • wishlist

    • Gossip protocol independent of project

    • external representation

    • language & library support

Alan Gardner: Phoenix and Elm

  • Elm has Model Update View pattern

    • Update looks somewhat similar to message receiving…​

  • Elm’s Signals: single value that changes over time…​

    • this is how Elm "changes state"

  • "Elm Architecture"

    • fold is where non-pure things can happen

  • interop with outside world (Ports?)

    • starting up the app, initial state takes inputs

    • init and update need to account for Effects

  • hooking Elm up to Phoenix…​

    • could run separately, old standard way of doing it…​

    • could compile and add as vendored JS…​

    • but you could embed Elm app into Phoenix and use brunch to compile

      • web/elm/ (not in static/)

      • elm-brunch plugin

        • actually start it up with some regular old app.js

  • Elm Ports…​ how outside world can interact with Elm

    • (not the same as erlang ports)

    • takes a JS data structure & constructs Elm-ish signature for it

    • need to explicitly map incoming data to (curried) Action s

      • and that becomes one of the inputs

Bryan Joseph: Elixir Beyond the Browser

  • goals

    • full or subset of Elixir into ES2015

    • complement elixir backends*

    • idiomatic Elixir

  • ESTree

    • including a thing that builds JS from Elixir code

  • ElixirScript: made of Compiler (in Elixir) and Runtime (in JS)

    • Compiler

      • value translation uses Symbol, custom things for binaries

      • use Patterns for "multiple" function defs/guards/destructuring params

      • uses JS modules (but scope isn’t same as in Elixir…​)

      • some current limitations: scopes, quote, ::, pattern-matching << >>

    • Runtime

      • most of the stdlib defined here

      • also some features for compiling (e.g. pattern matching)

  • how to "embrace the environment"

    • interop with JS

  • demos…​

    • reimplementation of React API!

    • running in an iOS app!

Jessica Kerr: Elixir Should Take Over the World

  • the March of Scientific Progress is presented as viewed through rose-tinted glasses…​

    • The Structure of Scientific Revolutions by Thomas S Kuhn, read it…​ coined "paradigm"

  • "Ideas are shared. Ideas keep coming. Ideas are shared."

    • when the groundwork is laid for a "new idea", many people will independently have it…​

  • good recent talks at StrangeLoop 2015:

  • circular dependencies are painful; neither pure functional nor object-oriented approaches are quite right…​

  • the way to success is more failures, and learn from them. "failure is the common case"

    • if you learn from the failures, they become part of the eventual succes

  • what’s next? (opinions…​)

    • after agile? lean. learn, build, measure, learn, build…​ (in theory that’s the scientific method, but scientists like proving their own points)

    • after no estimates? time ranges. wider range means more unknowns…​ at the end, "is it still worth it to do more of this?"

    • after scientific method? Brené Brown looks at human systems, "grounded theory" data, categories, theory, data, categories…​

    • after MVC? Elm architecture…​

    • after REST? GraphQL…​ maybe with backend-sourced events, channels…​

    • after microservices? better organized microservices.

      • …​microservices can easily end up circularly-dependent.

      • while working on your new thing, it’ll end up being more complex than you think, but if you wrapped everything in a nice API then from the outside world it’ll look sane

  • it takes lots of people (especially skill levels) to make progress

    • "Science advances one funeral at a time" —Max Planck

    • "we need people who don’t think like us"

    • smooth the stairs into a ramp!

  • big moustachioed Banana for Jim!

José Valim: State of the Language

  • what’s coming: extensibility: web infrastructure; embedded systems; financial/video platforms; GUIs

  • just out: v1.1

    • handy new functions!

    • ExUnit: can capture calls to Logger, will print on failures; @tag :not_implemented; line numbers in doctests fixed

    • Mix: profile.fprof

    • @callback instead of defcallback; @typedoc

    • deprecations…​ Access protocol (implementation became a bottleneck when protocols not compiled)

  • v1.2

    • gonna be Erlang >=18 only

    • multi-aliases alias MyApp.{Foo, Bar, Baz}

  • v1.3? just ideas here…​

    • GenRouter: separate process, multi-in/multi-out

      • adds supervision to stream-like things

      • source-driven, provides backpressure by default

      • inspired by Akka Streams

Lennart Fridén: Virtually Instructional

  • can compile elixir into Erlantg assembly: ERL_COMPILER_OPTIONS="'S'" elixirc file.ex

  • but Erlang functions get transformed by BEAM…​ so we’d need to look at a running system

    • :erts_debug.df MyApp creates a .

      • the function names end with their params' type signature…​

  • BEAM is register-based, unlike JAM, which was stack-based

    • bunch of functions will say how many registers are "active" (shouldn’t be GC’d?)

    • different types of registers…​ general, float, temporary, local vars

  • BEAM’s "assembly" is weird!

Steven Proctor: BEAMing with Joy

  • the Scheduler…​ is awesome. one per CPU. expensive to start up, so they stay up

  • monitoring

    • observer.start()

    • erlang’s c module if you don’t have a GUI…​

      • c.regs/0 is all registered processes/ports

      • c.i/0, bunch of other info…​

      • c.i/3 pass in your process info and get info about just that process

      • :c.bt/1 to look at backtrace of a :c.pid/3

  • types…​ strongly-held small set of types, also dynamic if you want it

    • elixir: optional typing using @spec

  • TypEr (pdf) adds type annotations to source code?

  • testing

    • Property testing: QuickCheck (not free), also PropEr

    • Concurrency testing: Concuerror

Nick DeMonner: OTP Has Done It

  • your technical problems aren’t unique…​ "we need to get over our reinvention addiction"

    • don’t keep using abstractions that aren’t useful!

  • supervisors

    • children are stopped in reverse of start order

  • (intro to all the gen_* things)

Ben Wilson: Streams, External Services, and OTP

  • StreamRunner by James Fish

    • makes an enumerable thing out of external service

  • but what about backpressure? StreamRouter

  • Collectable

James Smith: Interoperability in Elixir

  • can interop using JInterface, NIFs, and…​

  • ports

    • wraps an external thing, passes messages to it, passes messages out to the owning erlang process

    • Port.open/2, tons of options, docs pretty good

    • ETF External Term Format to convert any data into a binary format data == :erlang_binary_to_term(:erlang.term_to_binary(data))

    • can use stdin or also arbitrary file descriptors

Drew Olson: Composable Queries with Ecto

  • separate construction of query from execution…​ query = from(…​); Repo.all(query)

    • "the query itself is data" "very explicitly decoupled from [the Repo]"

  • Query Expression syntax…​ pull the keywords out into functions. query = where(Post, [p], p.published == true)

  • both syntaxes are composable! query2 = from(c in query, where: c.votes > 5)

  • "Query Pipelines"…​ inventing vocab for wrapping query expressions in nicely-named functions, then piping them together

    • "query source" the data source, e.g. a whole table

    • transformation modifies an existing query

    • sink executes query, returns result

Share Comment on Twitter
comments powered by Disqus