Elixir in the Real World

A Practical Introduction

Torey Heinz
GR Web Dev Meetup — February 23, 2026

whoami → Torey Heinz

Full-stack developer — 15+ years building web applications
Vianet Management — vianetmanagement.com
Shopflow — Founder — Software for small manufacturers
Started with Ruby on Rails → caught the Elixir bug

Vianet Management

Huge thanks to Vianet for fully embracing Elixir and giving us the freedom to adopt it across our stack.

The Factory

Coworking space in Grand Rapids

Puppies.com

Online puppy marketplace

Roommates.com

Roommate & room rental matching

OrbitFour

Domain registrar — no upselling

Reputable Rooms

Verified room & roommate search

RentProtect

Affordable renters insurance

What We're Covering Today

Three parts:

Why Elixir? — Where it comes from and why it matters
The Language — Pattern matching, processes, and LiveView (live demos!)
Real-World Code — Production systems at Vianet

Then we'll open it up for Q&A.

Part 1: Why Elixir?

Where it comes from and why you should care

Erlang & The BEAM

Built by Ericsson in 1986 for telecom switches — systems that literally could not go down.

The BEAM VM was designed from scratch for this:

Lightweight processes — ~2KB each, millions at once
Per-process GC — no stop-the-world pauses
Crash isolation — one process can't take down the app

Battle-tested for 40 years. 99.999999% uptime.
It just wasn't fun to work with...

Erlang was created by Ericsson in 1986 for telecom switches — systems that literally could not go down. Think phone networks: millions of simultaneous calls, where one dropped call can't crash the whole system. The uptime target? Nine nines — about 31 milliseconds of downtime per year.

The BEAM is the runtime, and it's fundamentally different from V8 or the JVM. Every request gets its own process — about 2KB each — millions concurrently. The scheduler is preemptive — in Node, one heavy request blocks the event loop; on the BEAM, every process gets a fair slice. GC happens per-process — no stop-the-world pauses. And crash isolation — if one request hits a bug, that process dies alone. The rest of your app doesn't notice.

The catch? Erlang syntax is... an acquired taste. That's where Elixir comes in.

Elixir (2012)

José Valim — Ruby on Rails core team member — asked:

“What if we took the best runtime in the world and made it a joy to write?”

Modern syntax — inspired by Ruby
Excellent tooling — Mix, Hex, ExUnit
Full Erlang access — 40 years of battle-tested libraries

Elixir doesn't replace Erlang. It runs on Erlang's BEAM.

Who's Using Elixir?

Companies choose Elixir when reliability and scale actually matter.

Discord

5M+ concurrent users, real-time messaging

Notification delivery, billions of events

Pepsi

Real-time manufacturing & logistics

Phoenix Demo (2015)

2M simultaneous WebSocket connections on a single server

Why It Matters for Web Apps

Concurrency — web apps are I/O bound; most time is spent waiting on databases, APIs, file systems
Fault tolerance — processes crash in isolation, supervisors auto-restart them
Real-time built in — WebSockets via Phoenix Channels & LiveView, no extra infrastructure
Background jobs built in — native processes + Oban replace Redis + Sidekiq/Bull

Let's Dive In

Now that you know why Elixir exists and who is using it,
let's look at what makes it different.

Next up: The Language — pattern matching, processes, and LiveView