Welcome to GigaElixir Gazette, your 5-minute digest of Elixir ecosystem news that actually matters 👋.

This week, we're unpacking three seismic shifts: Hologram's march toward 1.0, OTP 29 RC1 landing with changes you'll actually care about, and the growing case for building AI agents on the BEAM instead of reaching for Python. Let's get into it.

This is the release that makes Hologram impossible to ignore. 49 contributors ported 150 Erlang functions across 19 modules, catapulting client-side Erlang runtime coverage from 34% to 96% and overall Elixir standard library readiness from 74% to 87%. String processing, collections, sets, binary ops, Unicode normalization, math, time operations - all running in the browser, compiled from pure Elixir to JavaScript. The local-first angle is what makes this genuinely exciting. Most "full-stack Elixir" pitches still mean "server-rendered with sprinkles of JS." Hologram is building toward apps where the browser is a first-class execution environment for your Elixir code. With 96% runtime coverage, the gap between what works on the server and what works client-side is nearly closed. If you've been waiting for Hologram to hit critical mass before evaluating it, that moment is now.

Read more →

Erlang/OTP 29.0-rc1 just landed with a massive list of trouble reports and PRs addressed. The release tag references over 70 OTP issues and nearly 100 pull requests, signaling this is a substantial release cycle. If you're running production BEAM systems, now is the time to spin up your test suites against RC1 - not after the final release when you're scrambling. The sheer volume of changes here - spanning compiler, runtime, and standard library - means there's real potential for subtle behavioral shifts. Don't be the team that discovers an incompatibility in production. Pin OTP 29.0-rc1 in your CI matrix today, run your property-based tests, and report issues upstream while the Erlang team is still in fix-it mode. This is how you earn goodwill with the OTP team and protect your own deployments.

Read more →

Mark's new Sagents library - "Sage Agents" - is exactly the kind of AI tooling the Elixir needs: opinionated, BEAM-native, and built on GenServer architecture rather than porting Python patterns wholesale. It features human-in-the-loop oversight, sub-agents, Phoenix.Presence integration for real-time awareness and a middleware system. There's even a LiveView dashboard for debugging agent execution, message history, and tool calls in real time. Here's what matters: most AI agent frameworks treat concurrency as an afterthought. Sagents treats it as the foundation. GenServers managing agent state, Presence tracking active agents, LiveView giving you eyes on everything - this is what happens when you build AI tooling on a platform that was designed for concurrent, observable, fault-tolerant systems from day one. The Python can't replicate this without bolting on three separate infrastructure layers.

Read more →

Someone is building a probabilistic programming environment on the BEAM using Nx, inspired by PyMC. This is the kind of project that quietly shifts what's possible in the Elixir ML . Probabilistic programming - Bayesian inference, uncertainty quantification, generative modeling - has been almost exclusively a Python domain. Bringing it to Nx means you get BEAM's concurrency and fault tolerance wrapped around serious statistical computation. The practical implications are significant. Think A/B testing frameworks that quantify uncertainty natively, recommendation engines with proper Bayesian priors, or anomaly detection that gives you probability distributions instead of binary alerts - all running inside your existing Elixir application without a Python sidecar. Early days, but this is exactly the kind of ambitious Nx project that expands what Elixir developers can build without leaving the BEAM.

Read more →

A candid ElixirForum thread dissects why a CTO replatformed from Elixir to Next.js, citing hiring difficulty in a major EU city and a "narrow" library. The counterpoint from Remote's Marcelo Lebre: they had no trouble building an Elixir team. The difference? Remote hires remote. The CTO demanding hybrid in one city was artificially constraining a global talent pool, then blaming the language. The library argument deserves honest pushback too. If you're an experienced Elixir dev, your is real - Hex has what you need for web, data, and infrastructure work. The gap is in niche integrations that larger companies get for free. But the thread's sharpest insight comes from the comments: companies that drop Elixir for Next.js are trading BEAM resilience and operational simplicity for a wider hiring funnel. That trade looks smart on a spreadsheet until your first cascade of opaque JavaScript runtime errors at 3 AM.

Read more →

LiveView's "let it crash" philosophy is a gift from OTP-until it crashes your user's half-completed form and throws them into an infinite "Attempting to reconnect" loop. The Reddit thread from u/Rare_Friendship9405 surfaces a real production pain point that most LiveView tutorials gloss over: when a LiveView process dies, the socket reconnects, state resets, and your user is staring at a blank page, wondering what happened.

The comparison to React's Error Boundaries is telling-React solved this years ago because SPAs crash in predictable ways. LiveView crashes are more insidious because they nuke server-side state that the client can't reconstruct. The conventional wisdom says "let it crash and the supervisor restarts it." That's fine for background workers. It's terrible UX for a user mid-interaction. The real answer isn't error boundaries (which would fight OTP's grain) but defensive architecture: push ephemeral state into URL query params so reconnects restore context, isolate side effects into `Task.async` so a failed API call doesn't take down the whole view, and use `handle_info` with pattern matching to gracefully degrade when async work fails. The most underrated technique? Treating your `mount/3` as a recovery function, not just an initializatio function-if it can rebuild meaningful state from the session and params alone, crashes become invisibleto users.

The deeper lesson is that LiveView demands a different error model than traditional web apps. In a request/response cycle, errors are scoped to a single request. In LiveView, an error in a tiny callback can cascade and destroy an entire interactive session. You need to think about blast radius the same way you think about supervision trees: isolate components, keep critical state recoverable, and accept that "let it crash" means "let it crash *gracefully*." The teams that struggle with LiveView in production are almost always the ones treating it like a traditional MVC app instead of a stateful, long-lived process.

Remember:

Source →

That's the signal through the noise this week. The BEAM isn't waiting for permission - it's shipping. Stay sharp, ship code, and stop overthinking your stack.

Curious about OTP 29? Go read the release candidate notes yourself and form your own opinion - check out the OTP 29 RC1 announcement. And if you found this useful, forward it to a teammate who's still writing Python microservices for problems the BEAM solved in 1998.

Deploy your next Elixir app hassle-free with Gigalixir and focus more on coding, less on ops.

We're specifically designed to support all the features that make Elixir special, so you can keep building amazing things without becoming a DevOps expert.

See you next week,

Michael

P.S. Forward this to a friend who loves Elixir as much as you do 💜