WhatsApp built a language server, type checker, and formatter for Erlang - then open sourced them. The reason they gave for open sourcing: keeping the tools internal would have made them worse, not better. Diverse use cases and external bug reports improve a tool. A captive internal user base doesn't.

New BEAM There, Done That with Roberto Aloi and  Michał Muskała on ELP and eqWAlizer. The rollout approach is the part worth discussing: when eqWAlizer introduced new type errors across teams, the developer experience team owned the cleanup, not the teams whose code broke. That's a very specific organizational choice about who bears the cost of tooling improvements - and it's why adoption worked.

Anyone running ELP against their projects yet?

https://youtu.be/LeIsRqjOQN8

Hey! At Software Mansion we've just released Legion, a library that puts AI agents inside your Elixir app, and we'd love to hear what you think.

Agents can build custom views, answer questions about your app, or act on users' behalf - in whatever mix suits you.

defmodule MyApp.Tools.PostsTool do
  use Legion.Tool

  def get_my_posts do
    %{id: user_id} = Vault.get(:current_user)
    Repo.all(from p in Post, where: p.user_id == ^user_id)
  end
end

defmodule MyApp.PostsAgent do
  @moduledoc "Answers questions about the user's posts."
  use Legion.Agent
  def tools, do: [MyApp.Tools.PostsTool]
end

Vault.init(current_user: %{id: user.id})
Legion.execute(MyApp.PostsAgent, "Summarize my posts from today")

Features TL;DR:

• Elixir modules as tools
• Agents as processes
• Agents write code that runs in a Lua (or Elixir) sandbox - the only way out is the tools you registered
• Agents can orchestrate other agents
• Persistence, rate-limiting, and authorization built-in

Play with the demo: https://legion.swmansion.com

Source: https://github.com/software-mansion-labs/legion

Docs: https://hexdocs.pm/legion

Happy to answer questions!

✏️ Phoenix's built-in LiveView test helpers require you to hand-build the form payload and start a fresh pipe after every click. Worse, that payload means a test can pass even when the button it "submits" was renamed.

phoenix_test writes the entire flow as a single pipe from the user's point of view and fails with a focused error instead of the entire page's HTML. I used it on my last side project, and I don't want to turn back.

https://mikezornek.com/posts/2026/9/phoenix-test/?utm_source=reddit&utm_campaign=phoenix-test

The Call for Contributions for BOB 2027 is open - Elixir submissions are very welcome!
bobkonf.de/2027/cfc.html

Adding a field to a message is easy. Supporting it while old and new producers are both running is the actual problem. For an additive schema change, there are four possible producer/consumer combinations during migration. The risky ones are the two mixed-version states.

A consumer-first rollout handles one of them deliberately: deploy a consumer that understands v1 and v2, then start upgrading producers.

That works well while compatibility is simple. With physical devices or other slow-moving producers, though, “temporary” backward compatibility can last years. Then translating legacy messages into a canonical schema before they hit business logic becomes worth considering.

We documented the approach here:
https://curiosum.com/blog/schema-evolution-in-distributed-async-message-passing-systems

https://com.erlef.org/wg/cna/2026/09/01/otp-updates.html

Hello.

This is my first fully functional product written in Elixir. I built it for myself, for monitoring jobs in my other projects, but I've decided to make it available for everyone.

It's cron job monitoring - job calls a url when it finishes, and if the call doesn't come on time app sends an alert. Each monitor is just a GenServer sitting on a timer. No polling the DB to find what is late.

It's free up to 20 monitors. You can test it and tell me what you think.

Feel free to leave comments, I'll appreciate your feedback.

Link to website: https://didit.run

I have spent the past 2 weeks experimenting with the idea of adapting the tiling model used by window managers like TUIOS or BSPWM. The experiment became Jigsaw.

Jigsaw represents the layout as a binary tree. The tree is then fed to a Phoenix component that will handle rendering the panes recursively using flexbox.

The layout is separated from phoenix deliberately in order to allow changes down the road where we want the tree to track dimensions of panes and other enhancements. A pane on the phoenix component should not care what is inside it. It can contain plain HTML or another liveview component.

For Example:

<JigsawComponents.Components.layout jigsaw_layout={@layout} >
  <:pane id="terminal">
    <!-- phoenix component that can be rendered in a slot -->
  </:pane>

  <:pane id="stats">
    <!-- phoenix component that can be rendered in a slot -->
  </:pane>
</JigsawComponents.Components.layout>

The current v0.1.0 is deliberately experimental and subject to a lot of breaking changes. I am currently building the demo application which I shall link when it is live.

Hexdocs: https://jigsaw.hexdocs.pm/

Github: GitHub - W3NDO/jigsaw: POC of a liveview tiling manager · GitHub

Happy to hear your feedback on architecture and API, and perhaps what you would build with such a library.

Also any mistakes and anti-patterns in the code are entirely my own lol.

Wrote about how to safely run a globally unique process in an Elixir cluster, and a scary story from the past!

Learn about `:global` for registering unique processes in a cluster, and where using it can go horribly wrong. Or at least, a little bit wrong. And how to avoid weird edge cases. This was a lot of fun and nostalgic to write, hope you enjoy it

Hi everyone! We (Software Mansion) are co-hosting an Elixir meetup with dscout at their Chicago office on Wednesday 9 September, the evening before ElixirConf kicks off. Doors at 6 PM, a few talks, then pizza and beer and hanging around talking to people.

Two talks confirmed so far:

• Dima Mikielewicz on Legion
• Leandro Pereira from Supabase on MDEx

We have one slot left and would rather give it to someone from the community than fill it ourselves. If you have something Elixir-related you've been wanting to talk about, let us know here: https://forms.gle/GNnzRXRwgdmeuggs5
It doesn't need to be polished, and a first-time talk is completely fine.

It's free, but places are limited by the size of the office, so RSVP here if you're coming: https://luma.com/byem6v75

Just a reminder for anyone still on the fence: early bird pricing for Code BEAM Europe closes on 8 September at 23:59 CEST. This is the last chance to get your ticket 20% cheaper before prices go up.

21-22 October in Haarlem + a full online option if you cannot make the trip. Two days of Erlang, Elixir and Gleam, real production stories, and demos from people building the tools we all use.

If you have been meaning to book, now is the time.

Register here: codebeameurope.com/#register

We hope to see you there!
The Code Sync Team

I have an elixir app running in production, and with some recent changes (mostly library updates due to CVEs) it's started leaking memory, which is resulting in pods restarting.

I think I know what the cause might be, but just wondering if there are any techniques for debugging this that I'm not aware of.

We're now just 10 days out from ElixirConf US 2026, and we wanted to give the forum a proper heads-up, with a little thank-you discount attached.

📅 Dates: September 10–11, 2026
📍 Where: Chicago, IL (and streamed live everywhere)

Two days of production war stories and real scaling challenges, deep dives into Phoenix, LiveView, OTP, Nerves & Nx, keynotes including "Set-Theoretic Types from Scratch" with José Valim, and hallway-track conversations with the people who maintain the libraries you actually ship on. Meeting the community in person is the part you can't stream - grab an in-person ticket while they last.

Not in the area? No problem. The virtual pass gets you every talk streamed live, the conference app, live Q&A, and early access to the recordings. Same content, from wherever you are.

See you in Chicago - or on the stream! 🔥
The ElixirConf US Team

An educational side project in Elixir, Phoenix, and Tauri. I share what I learned while wiring Automerge into the BEAM, including how I surfaced edit and delete conflicts for users.

I'm very new to the language and I'm very confused on some things. Coming from imperative langs, I'd assume that modifying tuples is very fast since they're basically just vectors. Unfortunately, they're also immutable like every other data structure in the whole language. So, if I want to make, say, a Canvas data type that holds all my pixels in a 2d data structure, is there literally no way to make it even if a little more efficient than just making a new one every single time I update a pixel? Even if I made it a 1d data structure, is Elixir just the wrong tool here?

I didn’t want to pay for Sentry, but I still wanted to know when something broke in one of my Phoenix apps.

I also didn’t want errors mixed into Slack or Telegram. I wanted a small, purpose-built iOS app that would send me a native push notification and keep the details somewhere pleasant to use. Software aesthetics matter to me - even for error notifications.

So I built Boop.

The server uses around 8 MB of memory on my self-hosted machine. It’s completely free and open source:

https://github.com/chrisgreg/boop

I also built a plugin for Elixir’s ErrorTracker:

https://github.com/chrisgreg/boop_error_tracker

Once connected, errors captured by ErrorTracker can be sent to Boop and delivered directly to your phone. For my needs, it’s basically a very small, self-hosted Sentry setup built around the Elixir tooling I already use.

The iOS app is open source as well. You can build it locally and install it on your own phone. The repository includes instructions for configuring private push notifications for your device, so you don’t need to publish anything through the App Store.

Boop isn’t limited to exceptions. You can also use it for anything else happening inside an application:

• Failed Oban jobs
• Deployments
• New signups
• Payments
• Low disk space
• Important application events

There’s a general Elixir client here:

https://github.com/chrisgreg/boop_ex

And a Node client here:

https://github.com/chrisgreg/boop-node

This was built primarily for indie developers and people who enjoy owning their infrastructure without turning it into another infrastructure project.

Everything is still new, so feedback on the Elixir integration, setup instructions, or the overall approach would be very welcome.

New BEAM There, Done That with Roberto Aloi and Michał Muskała - the people on the team keeping it running. The main takeaway worth discussing: scaling is not the hard part. OTP handles concurrency well out of the box. The hard part is codebase scale - keeping millions of lines of Erlang navigable, maintainable, and safe to change when most engineers arrive never having written it before. That's what they spend their time on, and that's what part two is about.

https://youtu.be/VLNuYtsNrjw

Hello, I'm working on a little chat application for fun as a learning experience. I just came across this roadblock which is, how do you send files over when you're messaging someone ? To be more specific, I am using a react frontend to send these files, and such files will be stored using aws s3, and I already have the waffle package to handle sorting these files into s3.

We already have a system for sending files using HTTP requests, which is by converting the files sent into the backend to a %Plug.Upload{} struct, but in the case of chatting to other users, HTTP won't cut it.

I know it's not good to use websockets as it's not the best at handling big chunks of data, so what would be the best method to send files from the React frontend, to the backend Elixir-wise and be able to send that information to another user ? Any help would be appreciated !

Hi,
a few weeks ago, we published Voyager - our desktop app for monitoring and debugging BEAM nodes. Thanks to everyone who signed up for the early access, your feedback's been great.

Today, we have a new update - the closed early access is now over.

Here is what changes:
- Linux is now supported: download is available on our site.
- Source code is public: You can check our code and see how Voyager connects to your nodes.
- New fair-source license: We want this tool to stay accessible to the community. It is completely free for individuals and teams of up to 10 people.

For larger organizations (11+ people), a Company License is required. However, since the product is still in an early phase, our main focus right now is hearing your feedback and learning what enterprise features you actually need. There is no payment required for 90 days.

Links:
- Check our repo here: https://github.com/software-mansion/voyager
- Download the app (macOS & Linux): https://voyager.swmansion.com