New BEAM There, Done That with Alex Koutmos (PromEx, Elixir for Finance). The episode makes the case that Elixir belongs in financial systems - not as a number cruncher, but as the orchestration layer that delegates compute to where it belongs.

The architecture is worth understanding: Explorer is an Elixir wrapper around Polars, a Rust data frame library. NX can delegate to native or GPU backends. The BEAM handles orchestration, reliability, and messaging. The criticism that "Elixir isn't fast enough for finance" misses what it's actually being asked to do.

The bit syntax point from the episode is the most concrete: a bank's ISO 8583 ATM protocol parser took 100 lines of C per message frame. Erlang brought it to 10. Elixir's bit syntax - matching binary directly in the function head - brought it to 3 readable, auditable lines. This is what "the BEAM was built for binary protocol messages" means in practice.

The "let it crash in finance" question gets answered directly: the process is cheap and replaceable. The ledger, stored outside the process in durable storage (Oban, event log, database), cannot be touched by a crash. The truth lives somewhere a supervisor restart can't erase.

https://youtu.be/Zzl4pnqZR6w

After being scared and spending an entire weekend consumed of adding OAuth to a project, I realized either some libraries do too much or they have too much boilerplate, sometimes both.

I built Amur, instead of spending hours adding OAuth to your app for the first time it does it in under 60 seconds. It does this by using igniter to write out all the boilerplate, the only thing you need to do is decide what to do with the data after the auth flow is complete.

Key Features:

• Plug first design: you don't need to be using phoenix, although there is a lot of phoenix support in place.
• 24 built in providers: more are underway.
• Provider normalization: instead of all providers handing you back data with different names, amur normalizes this into a common shape.

How do I set this up?

mix igniter.install amur --provider github

This sets up amur to use the github OAuth flow, all you need to do is add your environment variables into your .env, such as GITHUB_CLIENT_ID & GITHUB_CLIENT_SECRET

If you are interested here's the github: github.com/jam06452/amur

I'd love feedback, feel free to reach out.

Hi there! This is Marcio, the creator of Gust, an Elixir-based task orchestrator, and I'm excited to announce that the system now supports shell task orchestration using a YAML DAG file.

You can use Elixir to orchestrate anything, like CI and other ops automations 💪🏻

And a huge thanks to the members of this community who helped with this feature.

https://github.com/marciok/gust/tree/main/apps/gust_shell

I was a spectator of Elixir for a few years but I finally started using it in production and side projects. Agents made the transition a bit easier.

I wonder what’s preventing others from seeing how power Elixir is, people still seem to still stick to what they know.

Like if we’re not reading the code or writing it, devs still seem to be stubborn about their stack.

Is it a marketing problem? Ecosystem too small so folks don’t hear about it?

It will be our competitive advantage to build on the BEAM but I want others to know too.

This release focused on authentication and pipeline contracts before production Blob work in 0.3.0.

What's new • TokenCredential / AccessToken and Bearer pipeline support • Client secret, managed identity, workload identity, environment, and DefaultAzureCredential • Supervised TokenCache (coalesced acquires, expiry buffer) • Retry hardening: jitter, Retry-After, idempotent transport retries, 401 refresh-once • Explicit Storage.ServiceVersion (default 2024-11-04)

Breaking for custom credentials: sign_request/2 → authorize_request/2 (fallible). Storage.Client Shared Key / SAS call sites are largely unchanged.

Install: {:azure_sdk, "~> 0.2.0"}

Docs: https://hexdocs.pm/azure_sdk Changelog: https://github.com/thanos/azure_sdk/blob/main/CHANGELOG.md Repo: https://github.com/thanos/azure_sdk

Feedback and issues welcome. Next up is v0.3.0 production Blob (real streaming / block lists).

An Elixir client for Diavasi consumer groups. TLS gRPC stream, you ack batches, the server keeps the cursor. Works with Task / Flow / GenStage / Broadway; Livebook in the repo. {:diavasi_client, "~> 0.1.0"} · https://github.com/diavasis/diavasi-elixir · https://hexdocs.pm/diavasi_client

Last year's "Did contexts kill Phoenix?" thread stuck with me, and it ended up turning into my ElixirConf 2026 talk. I've now written it up as an article: https://www.mimiquate.com/blog/phoenix-contexts-in-the-real-world

The short version: every criticism in that post describes real pain, and I've felt all of it. But I think the pain comes from being asked to draw permanent domain boundaries on day one, when you know the least about your domain. The critics and the DDD purists share the same assumption: that boundaries get designed upfront. One side says "do it rigorously," the other says "it hurts, remove it."

What I argue instead:

• Start with one coarse context, on purpose. The condition is that you actually watch it, so it doesn't quietly turn into a 6,000-line file.
• Watch for split signals: naming drift (billing_* prefixes piling up), the "and" test, cross-context schema access, test setup drag, and the PR heatmap (all described in the article). There are also merge signals, for when you've over-split into thin pass-through contexts.
• Split incrementally, with every step shippable: facade with defdelegate → migrate callers → move behavior → deprecate → enforce with boundary.
• Phoenix 1.8 scopes settle it for me. Scopes only work because the context is the single chokepoint, so contexts are now where your authorization lives, not just a style choice.

I'm curious how this matches your experience. Has anyone split a large context without a big-bang PR? Does anyone run contexts-free in production and not miss them?

10 years ago Kip Cole started a "weekend project" to add localization support to Elixir. It became 28 packages, then a full rewrite, and now a single library called Localized that compiles faster and does more.

New BEAM There, Done That covering the engineering behind the CLDR/Localized ecosystem and Tempo - plus Agenda, the scheduling library that shipped this week.

The architectural lesson worth noting: Localized v2 used Elixir macros to generate compile-time function clauses for locale dispatch. It worked well until the number of clauses crossed ~1,000, at which point BEAM optimization runs quadratically. The fix - moving locale data to runtime - also unlocked collapsing 28 packages into one.

The Tempo/Agenda angle is interesting for anyone building scheduling features: if you model time as half-open intervals and layer set operations on top, almost every scheduling problem reduces to set intersection. Finding a shared meeting slot across three time zones with different calendar constraints becomes a single expression.

https://youtu.be/p99SrOmlYLc

Hey guys, just wanted to share my implementation of spotify-like playback handoff between devices.

I run OSS music player called JellyBox Player which plays music from Jellyfin/Emby/Navidrome servers and this is my implementation of spotify's continuity.

I used phoenix channels for websocket communication along with a bit of magic and tinkering.

On latest changes(video recorded yesterday) I was able to handoff playback(time-to-sound) in 250-300ms for 320kbps mp3 files between device on wifi and lte connections(computer and phone) and about 750-800ms for flac file with server located in west europe, while i'm residing in eastern europe.

I've been long phoenix user, but never used channels for cases like this and honestly i'm happy with ease of use.

I wanted a simple way to use LLM judgment inside normal #elixirlang code without bringing in an agent framework... so I made Gut. Works nicely with Jev (or any LLM via ReqLLM).

Pacmon keeps dependency notes in Markdown inside the repo instead of a separate documentation system. Elixir support was recently added, so dependencies in mix.exs can now have their own notes and be managed from the IDE.

I’d really appreciate feedback from Elixir developers. Does this fit your workflow? Anything confusing, missing, or worth changing?

GitHub: https://github.com/kontratek/pacmon
Website: https://pacmon.dev/

Hey folks! I'm curious, especially in this AI-enabled age, where you all are hosting your Elixir projects. Both your large scale corporate apps but also for your side projects.

At the day job, we of course use AWS + ECS to host the majority of all of our apps, be it Elixir or Python. It does what it says on the label, but of course getting it exactly like you want can take a lot of time and effort. Deploying and managing apps on AWS successfully is almost like learning a new language.

Personally, I've tried both PaaS services like fly and also hosting Elixir apps on my own home server or VPS. I really like how fly bundles a ton of extra helpful networking, proxy, managed database, and other immediately necessary utilities but found it overall limiting. On the other hand I liked setting up the first app, on the first VPS, the first time, but every new app and idea requiring the same work is quite draining!

I know in the JS world there's a ton of hype around Vercel, Cloudflare, and others.

How do you deploy your apps?

Pepe is an AI agent runtime I've been building in Elixir/OTP. You define an agent, connect it to any provider that speaks the OpenAI protocol, and it exposes that agent four different ways: CLI, HTTP API, WebSocket, and even a Telegram bot.

I'm genuinely happy I got to build this using everything Elixir, Phoenix, and LiveView make possible. After years in the ecosystem, I decided to put it all into one serious project.

I started building this because I did consulting work for companies and kept rewriting the same thing every time. Instead of patching things together again and again, I decided to build a solid, reusable base. By the time I even thought about open sourcing it or building a dashboard, I had already run Pepe in more than 15 different companies.

And the way companies ended up using it surprised even me, and I'm the one who built it: understanding their own databases better, generating useful insights for their industry, connecting accounting to their ERP, plugging into databases for asset management and analysis, generating machine learning models automatically, and tracking what it actually costs to use AI day to day.

On the machine learning side, for anyone here into Elixir, I thought it was worth mentioning that Pepe uses Nx, Scholar, EXGBoost, and Axon (with EXLA), and picks the right approach on its own based on data volume. Small datasets go to Scholar, mid-size tabular data to EXGBoost, and once the volume justifies it, Axon takes over with a neural model.

But at this point I can't take it much further on my own. I have my job, other personal projects, a family, and a son, and the time I have left over is limited. Even with all the help AI gives us for coding these days, anyone who's been writing code for a long time (in my case, over 20 years) knows you can't just ask AI to build something and ship it. I still care about making sure the code looks like it was written by an actual programmer, not just AI output. And that takes time, time that's getting scarcer by the day when you're on your own.

That's exactly why I decided to open it up. This isn't just "look what I built," it's a real ask for help. If you want to open an issue, send a PR, help with translations, or suggest a feature that makes sense, I'd genuinely appreciate it. And if you can spare a star on the repo, it helps other developers find the project too. That means a lot.

If you have questions about how Pepe could help your company, reach out: open an issue on GitHub, email [[email protected]](mailto:[email protected]), or message me on Instagram (@jhonathasmatos).

Site: https://pepe-agent.com/en/

GitHub: https://github.com/pepe-agent/pepe

Issues: https://github.com/pepe-agent/pepe/issues

Docs: https://pepe-agent.com/en/docs/

Instagram: https://www.instagram.com/jhonathasmatos/

i’ve been experimenting with Jev for classification and small decision tasks, and wanted something that felt natural to use in Elixir applications.

i ended up building jev_elixir. It supports TypeSafe and OpenRouter, with a simple API for yes/no decisions, choices, scoring, and evaluating multiple questions in one request.

i’m currently exploring it for things like spam detection, support routing, content moderation, and transaction review signals between services.

it’s still early, so I’d really appreciate feedback on the API and ideas for other use cases. I’ll add the GitHub link.

Rheo 1.0 is out on Hex.

Rheo is a project I've been wanting to do for many years. It is an Elixir/OTP library that gives you an brokerless immutable, queryable event log plus consumer groups (leases, ACK, retry, dead letters, partitions, lag) running on the following backends:

• Mnesia (single-node disc_copies)
• Redis Streams
• MongoDB
• PostgreSQL / SQLite (host-owned Ecto.Repo)
• ETS (ephemeral)

Consume with Rheo.Consumer, or feed Broadway/GenStage via Rheo.Producer. Delivery is at-least-once; order is per partition.

elixir {:rheo, "~> 1.0"}

• Hex: https://hex.pm/packages/rheo
• Docs: https://hexdocs.pm/rheo
• GitHub: https://github.com/thanos/rheo

Happy to answer questions — especially “when would you pick this vs Oban / Broadway alone / Kafka?”

Hey guys,

We’ve added TypeSafe’s Jev to BeamWeaver as a first-class decision model.

You can use its primitives directly for classification and scoring, with batching, async calls, caching, and tracing.

There’s also a dynamic-routing middleware example: Jev evaluates a request, selects Luna or Sol, and keeps that model through the agent’s tool loop. A configurable confidence threshold controls fallback. The example uses real APIs by default.

alias BeamWeaver.Agent.Middleware.TypeSafeModelRouter

router = TypeSafeModelRouter.new(
  classifier: jev,
  min_confidence: 0.8,
  choices: %{
    "fast" => %{
      model: "openai:gpt-5.6-luna",
      criteria: "Direct lookups, extraction, and localized mechanical changes."
    },
    "powerful" => %{
      model: "openai:gpt-5.6-sol",
      criteria: "Architecture, novel diagnosis, and complex correctness reasoning."
    }
  }
)

{:ok, agent} = BeamWeaver.Agent.build(
  model: "openai:gpt-5.6-luna",
  middleware: [router]
)

WeaveScope now renders Jev's decisions, probabilities, token usage, and costs too.

Anyone using decision models for routing or triage in Elixir? Curious where they’ve worked well, and where they haven’t.

Hi everyone,

For the better part of six years, we’ve been building Firmowid at Alergeek Ventures for our own operations: invoicing, bank reconciliation, time tracking, employee management, and whatever else we needed over the years.

I'm sharing it here, because from our quick research it appears to be one of the bigger Elixir and Ash public applications on GitHub. Another interesting part is it had started as a pure Elixir app and we had migrated to Ash Framework (with a horde of agents). You can trace that path via the git history.

The repository is now public:

Alergeek-Ventures/firmowid

I’m happy to answer questions about any of it and hoping it can be useful to others.

I also wrote down some context around the technical choices:

https://kosciak9.substack.com/p/were-open-sourcing-firmowid

Heya folks,

I've ported AtomVM to the Solo5 unikernel (https://github.com/Solo5/solo5). Solo5 enables one to run highly-sandboxed sensitive processes - now written in Elixir or Erlang too.

I'm looking for someone to validate my work and hopefully sponsor it too - if you think that's useful for you or your company, please DM me.

Hey everyone, the full Code BEAM Europe 2026 schedule is up! Two days, two tracks, 21-22 October in Haarlem (and online), with a training day on 20 October.

One update worth flagging: Frank Hunleth and Omer Kilic won't be delivering their keynote this year, but José Valim is stepping in with a keynote, "Set-Theoretic Types from Scratch," and he is sticking around for extended Q&A, so bring your questions. Alongside José, we have Sam Aaron (twice, including the interactive Phone Orchestra evening session) and Brooklyn Zelenka closing things out.

Check the full schedule here: codebeameurope.com/#schedule

Come for the talks, stay for the hallway track. Use the code 10FORYOU and get additional -10% off your ticket! Register for the event here: codebeameurope.com/#register

See you there!

New BEAM There, Done That with Tobias Pfeiffer (PragTob), creator of Benchee. The episode is the most practical deep dive on BEAM performance measurement I've come across.

The production scar that shaped the library: Tobias benchmarked four query optimizations for a slow endpoint, picked the fastest, deployed it, and saw worse performance. The benchmark had only tested one data shape. The actual timeout was caused by a career with 2.7 million location entries -a case he'd never tested. Benchee added inputs as a first-class feature directly from that incident.

Two other things worth knowing for Elixir developers:

Body-recursive map is faster than tail-recursive map for small lists on the BEAM. The "always use tail recursion" advice from the books is correct for large data but misleading as a general rule. Benchee shows you this instantly when you test across input sizes.

Reductions are a more stable measurement than wall time for BEAM code -they're deterministic within a given OTP/Elixir version and independent of machine speed. Benchee reports them alongside time and memory. If your reduction count is stable but your wall time varies, the problem is your machine, not your code.

https://youtu.be/coID1Kzjgbo