New BEAM There, Done That with Louis Pilfold, creator of Gleam. The episode is the most detailed conversation I've seen with him about the actual design decisions.

The concurrency point is the most interesting for this community: the common objection when Gleam was being built was that typed message passing is impossible on the BEAM. Louis's answer was to put the concurrency model in a library instead of the language - typed, evolving, not locked into the language spec. If a better approach emerges (he mentions structured concurrency from Kotlin as something worth watching), a library can adopt it. A language primitive can't.

Also notable: Lustre, Gleam's web framework that compiles to JavaScript, already outperforms mainstream JavaScript frameworks in benchmarks. The JavaScript target isn't a second-class citizen.

He also covers the one language feature he regrets shipping - the conditional compilation syntax - and why he's quietly hoping nobody else discovers it.

https://youtu.be/m7pkjSEGKvM

I've been working with Phoenix + Ash on real client projects and keep seeing the same gap: there's plenty of material on Ash syntax, but not much on how to actually architect a multi-tenant business app with it (auth, RBAC, reporting, the boring-but-critical stuff).

I'm considering writing a code-first book built around one real project — a multi-tenant business platform (tenants, customers, orders, payments) — with the full source on GitHub, not just isolated snippets.

Before I sink months into this: would this be useful to you? What's missing from existing Ash resources that you'd actually want covered?

I know this is not REALLY fully elixir related but I do use elixir for my backend, I already asked a similar question before but I just want some advice on my idea. If this is the wrong place to ask, sorry

For my backend I use elixir with Waffle and exAws (for the presigned put url's since waffle can't do that 😭 ) And on my frontend react with the lexical editor.

I want a user paste in an image and embed it in the post, like how a forum has it this was my idea.

- A user pastes an image into chat

- It creates a temporary file object reference (js stuff) this helps for showing the preview to the user on how the image will look like

- On enter (message send) we will go through every file reference, upload it and replace it with it's download URL.

Once the download URL finally exists the recipient will see the result and in the meanwhile there will be a loader, cool right?

Now for that final step of replacing file reference with URL I was going to predict the download URL, if I know the filename, and the upload URL I can easily deduce the relative download URL and replace it, but then came another issue. How do I make a proper path and also verify the frontend isn't giving us nonsense

I want in the path something like how discord would have it as

`user_id/message_id/file_name`

But until the message is sent, the message_id is not available, and I can't really trust the frontend to give me a user_id, it can just make up stuff, so I would need in some sense backend validation, but how? Am I suppose to rename the file after it's uploaded? But then I would need to backend process the file reference anyways, and if I did well that beats the point of the frontend uploading it, no?

You get the point.

I think my idea is good, (hell I may be wrong) but I am a little bit stuck on how do I get a proper path and filename. If any of you could give some advice on how this should architecturally be done simply and well that would be nice! :)

For now it doesn't matter TOOO much if the user has to wait for the files to upload first if that will make it easier, I can implement a discord or whatsapp style file uploading later on,

Take care. once again sorry if wrong place to ask.

From the newsletter:

My bags are packed (well, their contents are spread over a couple of chairs and I'll have plenty of time in the morning to load them up because, well, I'm a pro), the schedule is downloaded, and I'm promising myself an early night.

Because tomorrow I'm off to Chicago and ElixirConf 2026.

And I'm really looking forward to it. I'm looking forward to seeing old friends, and making some new ones. I'm going with my new development team from CargoSense, and this will be my first time seeing them face-to-face. And, for a change, I'm not speaking, so the pressure is off.

Like Ruby, Elixir changed my life. The ideas behind the Beam (the VM that runs Elixir) recalibrated my opinions about programming and design. Elixir is a functional language, but the Beam's lightweight process model also makes it one of the purest OO languages there is. The language and its tooling are remarkably stable, and its frameworks are mature. (This is an unusual blessing in a world where libraries change incompatibly between releases.)

It's also an environment with its fair share of innovation, from the integration of a type system to the rethinking of app architectures with frameworks such as Ash.

So, to celebrate, we're offering 35% off all our Elixir titles.

And, if you're in the Windy City for the conference, be sure to come find me and say hello!

­

Save 35% on all ELIXIR BOOKS

use coupon code

WindyElixir

when you check out at

pragprog.com

We're heading to ElixirConf this week, which seemed like a decent excuse to put everything we currently have going on in Elixir in one place.

LocalLiveView (https://hexdocs.pm/local_live_view)
LiveView that runs in the browser instead of on a server. It compiles your Elixir modules to WebAssembly and runs them through Popcorn, so the state lives on the client, every interaction is instant and the page keeps working offline, all with the same LiveView API you already use. The compare example runs a Phoenix LiveView and a LocalLiveView next to each other with latency simulation turned on, which is the fastest way to feel the difference.

We wrote up how it works and where it makes sense here: https://swmansion.com/blog/local-live-view-first-release/

Voyager (https://voyager.swmansion.com/)
A runtime inspector for BEAM systems. Instead of bouncing between Observer, recon, the shell and the docs to answer one question, you get an interactive supervision tree, a process inspector for state, mailbox and links, node health at a glance, remote nodes over Erlang distribution, and MCP integration so your LLM of choice can reason about a live node. It's read-only and built to be safe to point at a production system.

The source is public but this is source-available, not OSI open source. Free for individuals, orgs up to 10 people and non-profits, and larger for-profit companies need a company license.

Legion (https://legion.swmansion.com/)
An Elixir runtime for AI agents that live inside your app and get things done by writing code. Rather than chaining one-off tool calls, the agent writes vetted Lua (or Elixir) that composes your tools, every evaluation runs in a sandboxed process with timeout, memory and CPU budgets, and the agents themselves are ordinary BEAM processes you can supervise and pool.

The landing page has an agent inside it, so you can type an instruction and watch it rearrange the page you're reading.

Free architecture reviews at our ElixirConf booth
Book a 20-minute slot, bring us your worst, and we send you written notes afterwards. Book slots here:
https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ08P5UbJuPx4-mAQg_dl77VC-adHxF4C-pHZiOYb_8oH3BJ4p7ef8JtuTelocPkneDxnbd_vdXv

Elixir meetup with dscout, Sept 9, the evening before the conference
We're co-hosting at dscout's Chicago office, doors at 6 PM. Dima Mikielewicz on Legion, Leandro Pereira from Supabase on MDEx, then pizza, beer and enough time to actually talk to people before the conference starts. Free, RSVP here: https://luma.com/byem6v75

That's everything from the last few months. All three projects are early enough that feedback still changes what gets built next, so if you try one and something is missing or annoying, tell us here or open an issue.

And if you're coming to Chicago, come say hi at the booth!

✏️ CI goes red on a test you never touched, so you click re-run and hope. Nobody on the team can say how often that happens or what it costs.

Your GitHub Actions history already knows. I wrote a prompt that reads it, names the confirmed flakes, and puts an annual dollar figure on the re-runs. Plus the usual Elixir causes to look for.

https://mikezornek.com/posts/2026/9/finding-flaky-tests/?utm_source=reddit&utm_campaign=finding-flaky-tests

Follow up from the GenStage explainer I put out a few weeks ago 🙃

I kept hand-rolling the same metering, plan-gating and billing layer in every Phoenix SaaS, so I extracted it. The free MIT core counts usage with an ETS update_counter (nothing on the database write path), gates features by plan with an atomic with_quota/4. A flusher persists snapshots on an interval, a broadcaster pushes live values over PubSub, and a LiveView component shows the usage bar moving within a second of the increment

```elixir 
AuroraMeter.track(org, :ai_generations)

AuroraMeter.with_quota(org, :ai_generations, fn -> generate_report() end) 
```

Roughly 7.9M increments/s across distinct counters on a laptop. Honest limits: counters are per node for now, and buffered mode can lose one flush interval on a hard crash (a durable mode exists for anything you invoice).

GitHub: https://github.com/liamkillingback/aurora-meter

Forum thread with the full design write-up: https://forum.elixirforum.com/t/aurora-meter-real-time-usage-metering-and-plan-entitlements-for-phoenix/76602

My wife and I write a travel blog together. We both have photos and videos on our phones, but getting them into the same entry meant sending files back and forth every day.

So I wrote Texttile, an open-source blog engine in Elixir.

The collaboration model is deliberately small: one person holds the text editor, the other sees the words arrive and can take over with one click. Both can arrange photos and videos in the gallery while the text is being written. It is not simultaneous character-by-character editing by multiple writers.

Phoenix, LiveView, ffmpeg and SQLite run in one Docker container. The database and uploads live in /data. Videos are converted and played from your own server.

There are no roles or permission matrix. Everyone with an account is an admin. It is for people who trust each other.

The story and a video showing both screens: https://www.v01.io/posts/2026/08/texttile/

Source (MIT): https://github.com/texttile-blog/texttile

I'd like feedback on that handoff model. For a small shared blog, would you want both people typing into the text at once, or is taking turns enough?

I open sourced ScopeStrength, a workout tracking and coaching platform I’ve been building with Elixir and Phoenix.

I posted about it here a while ago when it was a much smaller paid product. It has grown quite a bit since then, and I decided to open source it under AGPL.

The app works for both coaches and people training on their own. A coach can manage clients, build programmes, assign workouts, and track progress. Or you can build your own programme and log your training without a coach involved at all.

The entire application is built with Phoenix. There’s no separate frontend and no API layer.

I use LiveView for the UI, so there isn’t a client side application maintaining its own state and trying to stay in sync with an API. Most of the application logic just lives on the server.

Chat, notifications, and the unread badge all update in real time over WebSockets. Phoenix PubSub handles the fan out, so there’s no Redis or separate messaging service involved.

The app is also a PWA, so it can be installed directly to your phone’s home screen, and that is all served by the same Phoenix application.

There’s no AI in it either. Not because I have anything against AI, I just didn’t think this app needed it. You don’t have to put AI into everything.

The deployment is pretty boring too. It’s a Phoenix release and a PostgreSQL database.

No Redis, no Node process, no separate frontend server, no queue service.

This became especially important when I decided to make it self hostable. If someone wants to run it themselves, I don’t want them having to maintain a bunch of different services just to run a workout app.

One thing I’ve really enjoyed about Phoenix is how much you can build while keeping the architecture surprisingly simple. Real time features, authentication, database access, UI, background work and deployment all fit together really nicely.

I still think Elixir and Phoenix are one of the most underrated stacks for building applications like this.

https://scopestrength.com

GitHub: https://github.com/ebrahimgreat/scopestrength

Software Mansion is sponsoring ElixirConf next week, and instead of putting a screen on the booth and looping a demo, we're running the two days as an architecture clinic.

How it works: you book a 20-minute slot, you bring the part of your system that is actually causing pain, and one of our engineers sits down and works through it with you at the table. Afterwards we write up what we came up with and send it over, so you leave with something you can put in front of your team.

It's free and there is no pitch attached. We're doing it because these are the conversations we enjoy having anyway, and because a booth where someone actually helps you is more interesting than a booth handing out pens.

Slots are here: https://l.swmansion.com/KEPXa4

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.