u/ancatrusca0

New BEAM There, Done That with the author of Bandit - the pure Elixir web server now default in Phoenix. Covers the HPACK debugging nightmare, what one-process-per-connection actually buys you at 3am, and why there's an AI-generated HTTP/3 PR sitting open on the repo that Mat hasn't merged.

He uses agents for everything in his day job. Bandit stays handwritten. The episode is honest about why.

https://youtu.be/XXQcoz_dTE0

New BEAM There, Done That with Maxim Kharchenko, creator of LING - a from-scratch Erlang VM running directly on Xen with no Linux kernel.

The part I hadn't seen discussed before: Ling's instruction set isn't fixed. It analyzes real OTP source, identifies frequently occurring patterns, and generates specialized opcodes - if loading the constant 17 is common enough, 17 gets its own instruction. More opcodes means a bigger VM and slower dispatch, so a heuristic manages the tradeoff.

Also: every allocation in the codebase has an explicit out-of-memory handler. Not convention - a whole-system discipline.

Francesco notes the problems Ling solved ten years ago have come back as unikernels and eBPF. Is anyone here doing bare-metal or near-bare-metal BEAM deployments today?

https://youtu.be/ILEyncf194M

New BEAM There, Done That with Mike Williams (who wrote the JAM emulator) and Björn Gustavsson (who built the BEAM). The most historically significant episode the show has done.

Two things from the conversation I hadn't fully appreciated before:

1. The three numbers that decide a concurrent language. Mike measured this directly in the early 80s: process creation time, context switch time, and message copy time. On real telecom workloads, 70% of VM time was those three operations - not application code. The JAM was built to make those fast first, everything else second. That's why getting message passing to six instructions mattered.

2. Memory, not speed, was the constraint. Whole-city phone switches ran on 16–64 MB of RAM. Every instruction set decision was a memory decision first. The JAM files were small. The early BEAM was faster but used significantly more memory - Björn spent years reducing BEAM instruction size to close that gap.

There's also a great moment where Mike mentions Claes Wikström - who invented ETS tables, added distribution to the JAM, and prototyped the binary syntax - as someone who always gets forgotten in these histories.

What design decision from this era do you think has aged best?

https://youtu.be/sRTierdN9c4

Bart Blast has spent six years - three full time - building Hologram: a framework that compiles Elixir to JavaScript and rebuilds the Erlang runtime in the browser, including a real pattern matching engine, boxed types, and OTP guarantees.

New BEAM There, Done That episode where he makes the case.

Two things I hadn't thought about clearly before:

1. Most UI state is ephemeral by nature. A menu being open, what you've hovered, a half-typed form. None of that needs to be on a server. Putting it there - and then making the server durable to keep it alive - is solving a problem you created by putting it there in the first place.

2. The latency ceiling is genuinely a physics problem. No amount of server optimization or bandwidth improvement changes the speed-of-light round trip on every interaction. Running logic in the browser eliminates it. This is the actual ceiling Bart is designing around.

He's also direct about where Live View still wins - private logic, data-heavy apps, maturity. No pretense that Hologram is a replacement for everything.

Anyone here actually running Hologram in a real project? And what does the "actions vs. commands" mental model feel like in practice compared to Live View's event handling?

https://youtu.be/BOsSI7WlhdI