We get asked about Elixir a lot, usually by teams who know Ruby or Node well and have heard good things about Phoenix. The question is almost always the same: is it worth adopting now, especially with so much code being written by AI agents?
This post is a snapshot of where the language and its main web stack stand this fall. We’ll keep it to what has shipped.
Elixir v1.20: a gradually typed language
The big news this year is Elixir v1.20, released June 3. José Valim’s announcement sums it up: with this release the team completed its first milestone, which was “to perform type inference and gradually type check every Elixir program, without introducing type annotations.”
In practice, that means the compiler now reports two kinds of problems in code you’ve already written:
- Dead code. Clauses that can never match.
- Verified bugs. In the release post’s words, “typing violations that are guaranteed to fail at runtime if executed.”
You don’t have to add annotations to get this. The v1.20 release notes walk through what it can infer. A guard like when is_map_key(x, :foo) tells the compiler x is a map with a :foo key. A function body like data.foo + data.bar tells it the argument must be a map with those keys, holding integers or floats. The changelog adds inference across clauses, occurrence typing on case, cond and with, and warnings for redundant clauses.
The release requires Erlang/OTP 27 or later and is compatible with OTP 29.
What’s next for the type system
Type signatures aren’t here yet. The release post lists what has to happen first: the team needs to be happy with type-checking performance, and needs efficient implementations of recursive types, parametric types and a way to treat map key-value pairs as an enumerable. Typed structs and then type signatures come after that. This was planned well ahead: the January post announcing the first release candidate, on Elixir’s 15th birthday, laid out the release-candidate schedule month by month.
Why types matter more when agents write code
This is our take, not something from the release notes. If an agent writes a large share of your code and you’re reviewing rather than typing, you want the compiler to catch as much as possible before a human looks. An agent that misreads a data shape tends to produce code that looks fine. A type checker that flags guaranteed failures, with no annotations to keep up to date, is a cheap safety net.
Phoenix LiveView 1.2
LiveView 1.2 shipped June 10. The headline is colocated CSS: you can keep styles next to the component that uses them. The team deliberately didn’t ship scoping by default, because the CSS @scope rule wasn’t yet well supported across browsers. Instead there’s a behaviour you can implement for your own scoping strategy.
The smaller changes are the kind you notice day to day:
- A
TagFormatterbehaviour for formatting certain embedded tags in HEEx with a tool of your choice (the docs show prettier) Phoenix.LiveView.JSstructs encoded automatically when sent withpush_event- HEEx debug annotations configurable per module
- Test warnings configurable by category
- Separate documentation for the JavaScript client
Upgrading from 1.1 is a version bump in mix.exs.
Tidewave: tooling for coding agents in Phoenix
Tidewave connects coding agents to a running Phoenix app through MCP, so an agent can do more than read files. The changelog shows steady releases this year:
- v0.9.1 (September 23):
mix tidewave.proxy, and instructions included in the MCP initialization response - v0.9.0 (August 18): a
create_design_canvastool, and removal of theget_*_schematools - v0.8.3 (August 13): LiveView patching diagnostics
- v0.8.1 (July 29): Tidewave Connect support
The direction is clear: give agents the same view of a running app that a developer has, instead of asking them to guess from source files alone.
So, should you pick Elixir now?
Our honest answer hasn’t changed much, but the reasons have shifted:
- It’s a great fit for real-time features, many concurrent connections, background work, and systems that need to keep running when parts fail. That’s what the BEAM was built for.
- The type system removes one of the most common objections from teams coming from typed languages, without making you write type annotations.
- The tooling for agents is real and maintained by people close to the core team.
The open question is how well general-purpose coding agents write idiomatic Elixir without that tooling. Elixir works best when you design around processes and messages rather than copying patterns from Rails or Express. An agent told to port an app one-to-one will often copy the old design, and that can hide what the platform is good at. We expect that question to get more attention soon.
If you’re weighing Elixir for a new product or a rewrite, we’re happy to talk it through. Book a call.
