--- title: "Elixir in Fall 2026: Gradual Types and LiveView 1.2" description: "Where Elixir stands in fall 2026: v1.20's gradual type system, Phoenix LiveView 1.2, and Tidewave for AI-assisted Phoenix development." url: https://axiointelligence.com/blog/elixir_fall_2026 --- [← Blog](https://axiointelligence.com/blog) Elixir, Phoenix, LiveView, AI coding # Elixir in fall 2026: gradual types, LiveView 1.2 and AI coding tools Brice Ayres / October 3, 2026 Short answer Elixir v1.20, released June 3, 2026, made Elixir a gradually typed language that finds verified bugs and dead code without type annotations. Phoenix LiveView 1.2 added colocated CSS and smaller quality-of-life fixes, and Tidewave keeps adding tools for coding agents working inside Phoenix apps. If you last looked at Elixir a few years ago, the language is safer and better suited to AI-assisted work than it was. 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](https://elixir-lang.org/blog/2026/06/03/elixir-v1-20-0-released/), 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](https://github.com/elixir-lang/elixir/releases/tag/v1.20.0) 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](https://github.com/elixir-lang/elixir/blob/v1.20.0/CHANGELOG.md) 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](https://elixir-lang.org/blog/2026/01/09/type-inference-of-all-and-next-15/), 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](https://phoenixframework.org/blog/phoenix-liveview-1-2-released) 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 `TagFormatter` behaviour for formatting certain embedded tags in HEEx with a tool of your choice (the docs show prettier) - `Phoenix.LiveView.JS` structs encoded automatically when sent with `push_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](https://github.com/tidewave-ai/tidewave_phoenix/blob/main/CHANGELOG.md) 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_canvas` tool, and removal of the `get_*_schema` tools - **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](https://axiointelligence.com/book). ## We do this work for a living. A 30-minute scoping call with the engineers who would do the work. [Book a scoping call](https://axiointelligence.com/book) Or email [contact@axiointelligence.com](mailto:contact@axiointelligence.com?subject=Project%20inquiry) and we’ll reply. ## Related posts Oct 11, 2026 ### [DHH's Campfire shootout, part 2: the Elixir port played by different rules](https://axiointelligence.com/blog/dhh_campfire_shootout_part_2) The Campfire repos show Rust could drop Redis and diverge from Rails while Elixir PRs doing the same were turned down. What a fair benchmark needs. Elixir, Rust, benchmarks Oct 10, 2026 ### [Fast isn't the same as reliable: what the Campfire reliability test shows](https://axiointelligence.com/blog/fast_isnt_reliable) A reliability test of the Campfire ports: Rust is fastest at light load but drops most messages under heavy load. Rails and Elixir delivered every one. Elixir, Rust, reliability Oct 6, 2026 ### [398 commits vs 2: how to run a fair language benchmark with AI-written code](https://axiointelligence.com/blog/fair_language_benchmark) The Campfire Rust port had about 400 commits before the benchmark. The Elixir port had two. How to run a fair benchmark when AI agents write the code. benchmarks, Rust, Elixir