u/rtrusca

New BEAM There, Done That with Annette Bieniusa (RPTU, Germany) and Guillaume Duboc (Dashbit, PhD from IRIF Paris) on the theoretical and practical story behind what's shipping in Elixir 1.20.

The episode covers the set-theoretic foundation, the gradual design, and the long history of failed attempts at typing Erlang since 1995. But the thing that stuck with me most was the framing of what the type system is and isn't trying to do:

The BEAM ran telecoms for 25 years without static types, with seconds of downtime per year. Supervision trees and let it crash handle an entirely different class of failures from what a type checker catches. The argument for types here isn't that the runtime is broken - it's that type errors are a separate cost (restarts, latency, overprovisioning) that supervision handles but doesn't eliminate. Even catching 5% of those at compile time instead has measurable infrastructure impact.

What got me thinking: the episode raises the false confidence risk - developers seeing types and writing fewer supervision trees, less defensive code, no recovery strategy. Has anyone here actually observed this shift in teams adopting typed languages? And do you think the BEAM community is more or less susceptible to it than others, given how explicitly OTP teaches you to expect failure?

https://youtu.be/X_CPDt3PeDE?si=yJTRAwlAaf7h2rlZ

New BEAM There, Done That episode with Björn Gustafsson (OTP team since 1996) tracing the BEAM's origins through three competing VMs - JAM, Robert Virding's V, and Bogdan's original BEAM.

The most counterintuitive part: native-compiled Erlang showed massive sequential speedups in isolation, but once concurrency entered the picture, the real-world gain shrank to about 2x, because message passing was already implemented in C regardless of compilation target.

Also covered: the BEAM Validator, built after a compiler bug caused weeks of debugging pain, and the BEAM loader - Björn's own invention, still running in production decades later.

https://youtu.be/1Ty_MHZu9nM?si=L99dI6FvwNJi46S2

New BEAM There, Done That episode with Chris Beck of Bitcrowd, on building an open-source alternative to BlueSky's data plane: the component that turns the AT Protocol firehose into an actual user timeline.

The target was millions of users and roughly 10,000 messages/second. The reference implementation tops out around a few hundred thousand. BlueSky's own production system handles millions but needs infrastructure most teams can't replicate (similar story to Discord's MongoDB → Cassandra → ScyllaDB migration).

The team evaluated Go, Rust, and Node first. All three got rejected for structural reasons: Go's GC pauses, Rust's slower iteration speed for a project requiring constant experimentation, and Node's single-threaded scheduler, which is exactly why BlueSky's own team already moved off it.

# ETS covers most of the "raw compute" gap for free
:ets.new(:timelines, [:set, :public, :named_table])
:ets.insert(:timelines, {user_id, posts})

# the one place pure Elixir genuinely couldn't keep up:
defmodule SocialProof do
  use Rustler, otp_app: :data_plane, crate: "roaring_nif"
  def mutual_follows(_a, _b), do: :erlang.nif_error(:not_loaded)
end

The honest part : Elixir loses nearly every microbenchmark against the alternatives. Chris' response was basically, do you actually need to go there? ETS plus BEAM's natural backpressure handling covered enough of the workload that raw compute wins on paper stopped mattering, except for one feature (mutual follows / social proof) that got a Rust NIF via Rustler.

https://youtu.be/UDNfwsbshI8

New BEAM There, Done That with Elise Sedeno on using OTP for game backends - supervised per-player/per-mob processes, no shared state, no deadlocks, and why call vs cast choices matter for avoiding circular waits between server processes.

Open source on Codeberg (game_server). https://youtu.be/4MDObD_R5E4

bitcrowd evaluated all four (Go, Rust, Node, Elixir) for a high-performance Bluesky DataPlane and landed somewhere they didn't anticipate.

The key insight: the workload splits cleanly into a hot path (timeline reads, memory-resident, concurrency-bound) and a cold path (records/threads/profiles, I/O-bound). Once you see that split, the language choice follows from it.

Elixir's weakness — raw per-core compute — is real, but it sits in exactly one place: follower-graph set operations over Roaring Bitmaps. They offload that to a small Rust NIF, and the data-flow shape makes the boundary nearly free (tiny data crosses, the big graph and heavy compute stay native).

What Elixir wins on is everything that remains: high-concurrency request serving and an in-process fan-out queue using GenStage/Broadway — no Redis, no Kafka, no second system to operate.

Full write-up: https://bitcrowd.dev/why-elixir-bluesky-dataplane

New BEAM There, Done That episode that I think deserves more discussion than it'll probably get, because it's uncomfortable.

Bruce Tate (Seven Languages in Seven Weeks, Groxio) just shut down a 10-year mentoring organization. Not because mentoring stopped mattering - because the career path for junior developers had become too unclear to build a program around.

The core argument: the productivity dividend from AI is real, but most organizations are consuming it instead of reinvesting it. Juniors ship more code than ever and learn less than ever. Seniors review more code than ever and do less architecture than ever. Management sees green dashboards and doesn't know what they're not measuring.

Some things specific to the BEAM ecosystem worth discussing:

elixir
# The two patterns Bruce flags as most common AI mistakes in Elixir:

# 1. Tag tuples leaking into functional cores
# (should be a boundary concern, not a core concern)
defmodule MyCore do
  def process(value) do
{:ok, transform(value)}  # <- wrong layer for this
  end
end

# 2. LiveView components used to share/encapsulate state
# (replicates stateful UI architecture, fights the model)

On the positive side: Bruce makes the case that Elixir might be the best language for AI-assisted development - gradual typing, explicit structure, uniformity of tooling, and frameworks like Ash that let agents model domains and derive the rest.

The four things he says juniors need to develop to actually become seniors:

1. Get comfortable throwing code away
2. Only ship what you understand
3. Translate your senior's feedback into your prompting architecture
4. Take your time and finish your work

Curious whether people here are seeing the same patterns - seniors drowning in AI-generated PRs, juniors shipping volume without learning architecture. And whether anyone's found ways to actually fix it at the org level.

https://youtu.be/KvBd8kVvwCY

Someone called it the "oh f*** moment." I think that's accurate. 😬

New BEAM There, Done That episode with Peter Ullrich and Jonathan Machen (EEF CISO) on something the community really needs to talk about: AI-assisted vulnerability research just arrived in our ecosystem, whether we're ready or not.

Peter had no security background. He wrote a bash script, fed Hex packages file-by-file to Claude Opus, and found a critical crash vulnerability in decimal - one of the most downloaded libraries in the ecosystem - in under 30 minutes. Then kept going.

The episode covers:

• the exact setup he used (prompts are open source)
• atom table exhaustion, binary_to_term, and the patterns showing up again and again
• how the EEF CNA coordinates disclosure with maintainers
• what happens when a maintainer is unreachable or a library is abandoned
• the gap between what's been built and what the current volume demands

elixir
# What Peter found in the decimal library
iex> Decimal.new("1.0e10000000") |> Decimal.add(Decimal.new("1"))
# memory: 8gb, application: gone

Genuinely one of the more important ecosystem conversations I've heard in a while. Curious whether people here are already scanning their own libraries, and what tooling you're using if so.

https://youtu.be/FulShj7jc0o 

New BEAM There, Done That episode with Adi Iyengar, who spent 3.5 years rebuilding Phoenix from scratch to understand the layers underneath.

defmodule MyFramework do

  use Plug.Router

  # accidentally reinvent Phoenix

end

Really good discussion on:

• Plug as the real core of Phoenix
• when metaprogramming helps vs hurts
• old BEAM web-server history (Yaws, Mochiweb, Inets)
• why coding agents still misunderstand Phoenix in 2026

Worth it if you’ve ever wanted to understand Phoenix beyond the generators.

https://youtu.be/jSCo5NvH2jY

New BEAM There, Done That episode with Florian Gilcher (Ferrous Systems) and Leandro Pereira (MDEx, BeaconCMS) dives into where Rust actually fits in Elixir systems — NIFs, ports, performance bottlenecks, and hybrid architectures.

case system do

  :cpu_bound -> Rust

  :distributed -> Elixir

  :both -> "why not both?"

end

Good discussion on when to stay on the BEAM vs when Rust genuinely helps instead of just adding complexity.

https://youtu.be/w5Pl09lpSmE