Elixir, Erlang, and OTP have done an amazing job taking us from the 1980s all the way to the 2020s! Is this the end? Have we found the one true path of productivity and expression? Are the assumptions from 10 years ago still applicable? This keynote will discuss new ways of working that go beyond instructions, text, pipes, and actors. This covers techniques can be applied to code today, plus extensions to the core language that can be implemented by anyone, and a call to action to bring the our tooling alongside the cutting edge.

For many of us, programming is fundamentally an exercise in transforming data. Whether to make decisions or render a webpage, nearly every use of software appears — at least at first — to come down to finding the correct way to manipulate data. Though convenient, this perspective obscures the deep connections inherent to the domains we find ourselves in.

Moving past this conception of programming as a purely mechanical activity means reifying the process of transforming data into knowledge, and here our traditional tools begin to fail us. In this talk, I'll share the lessons we can learn from the database designers and the logicians of the 70s, who paved the way toward being able to think about code in terms of the knowledge it computes, and I'll demonstrate how to apply these lessons to the Elixir applications we write today.

Burrito is a new open-source project that tries to tackle the distribution problem of Erlang and Elixir applications.

We'll discuss how we created a way to easily ship single file binaries for Windows, Mac, and Linux environments with minimal runtime and build-time dependencies.

Born from the requirement to run applications in potentially air-gapped environments, Burrito allows Elixir apps to be deployed to any modern machine (including the NIFs!)

No system Erlang installation required.

Get ready for an uncharted adventure through cross-complication, NIFs, Mix Releases, Zig, the C standard libraries, and Win32 APIs, Oh My!

One of the best secret features about Elixir, that (as far as I can tell) you can't get in any other language (not even Erlang!!) is the way it supports sharded global state in tests. Many of you have used this without knowing that you are using it if someone else has set it up for you. Many of you have set it up without knowing explicitly how it works under the hood. I'll take a “scientist's approach” and describe a model for how sharded global state works in tests and run a few experiments to prove that our “black box model” for the elixir standard library is correct. The best thing is this isn't just for tests! I'll show a non-test example at the end.

Networking is at the core of just about everything we do with Elixir, but the mechanisms that power the BEAM's legendary server performance are not super obvious to many developers. This is unfortunate, as the clever application of OTP design principles at the lowest levels of the network stack is one of the key ingredients that give Elixir and the BEAM their well-deserved reputation for incredible scale and performance.

This talk will go into depth on what these patterns look like, focusing on how they represent a tangible and textbook example of OTP design patterns. We'll take a close look at building process trees for robust & scalable performance, and provide some hard-earned rules of thumb for determining which process types to use where & how to supervise them effectively. Along the way, we'll also build a few simple network services to demonstrate the concepts underlying Elixir web servers such as Bandit and Cowboy.

You can expect to come away from this talk with a much deeper understanding of the process model that underlies every line of Phoenix code you'll ever write, and guidance about how to apply OTP patterns most effectively in your own code.

An ecosphere of connected things
to wit the world round them spins
Connected lights, audio mixers
Components and drivers written in Elixir
The developers mind spewing forth creativity
Unbounded, unfiltered, enamored with possibilities

But lo! The crux of designing such things,
when code defined cannot run in time,
and squiggly lines be rampant
For the target doth not match the host
And the hopeful device appears not connected
The fruitful dreams, vibrant, boundless
once destined to be
Destroyed
For you have not the dongle…for USB-C

Eventually, henceforth deployed it goes
the ideas have come to fruition!
But the physical world can behave in such ways to leave the mind a wonder
Within it's use, a curious case
Behavior erratic, undefined, unforseen
And the adage, as old as time itself
"But it works on my machine..."

But how does one overcome such tribulations
and develop expediently?
The answers may lie in the firmware design
Or, at the very least, what has not worked for me

What do Tensorflow, Airflow, Rule Engines, and Excel have in common? Under the hood they all use DAGs to model data-flow dependencies of the program. Using graphs to model programs is great because you can modify the program at runtime. Lets talk about doing this in Elixir for great good.

I've been building a tool in Elixir called Dagger. Dagger lets you compose arbitrary elixir functions and control flow into a data structure that can be evaluated lazily or eagerly with full tracing. The purpose of this tool is to compose programs at runtime. Composing programs at runtime is common in expert systems, rule engines, data pipelines, and anywhere where the program needs to change outside of your product development pipeline.

Dagger uses graphs, or DAGs (Directed Acyclic Graphs) to model data-flow dependencies between elixir functions. Evaluating a Dagger Workflow supplies “work to execute” that can run in parallel. The inherent parallelism in this model is why you'll find it in many systems such as Tensorflow, Apache BEAM, Apache Airflow, Excel, and more.

In June 2021 Cars.com launched a complete rewrite of its online marketplace. This new Elixir platform went from servicing a tiny fraction of requests (< 1%), to all of them, in roughly 12 hours.

How did we ramp up traffic while knowing that requests were being satisfied? How do we know that new releases are working as expected? How do we know when terrible things are happening on a server?

The answer: An umbrella child application named Meter, a bit of Telemetry, and a whole mess of trace data.

This practical talk will go through the architecture of how Cars.com uses Telemetry to generate performance data for all of our platform requests. We'll go over how we layer existing technologies and tools in the Elixir ecosystem into a child umbrella application that emits traces and metrics for the entire platform.

Along the way, we'll cover: What Telemetry is, how to use it, and how it acts as a force multiplier for our product teams. How we lean on third-party package Telemetry events to provide a default level of observability. How we use Telemetry.Metrics to monitor the BEAM itself. And all the gotchas we learned along the way.

LiveView empowers developers and teams to be highly productive by keeping your brain firmly focused on the server-side. Backed by OTP, it brings a fast and fault-tolerant UI to your web apps and enables you to build complex interactive and real-time features easily. In this training, you'll master the tools you need to be a productive LiveView developer.

We'll start with the basics of LiveView development and build on that to take a deeper dive into many of the core features that your LiveView apps will need in order to be production-ready. Over the course of building out a LiveView application, you'll learn how LiveView works under the hood to support interactive UIs, you'll secure your live views with authentication and authorization, you'll architect a complex, layered UI with LiveView components, you'll bring real-time features to your live views with Phoenix PubSub, and you'll explore some of the latest LiveView features that let you support sophisticated user interactions with custom JavaScript, maintain and restore LiveView state in the event of a disconnect, upload files to your LiveView forms with ease, and more. By the end of the day, you'll be well on your way to LiveView mastery.