Thanks for compiling this. As a CTO running Elixir for 3 years (1 year of MVP deployed in production), my take is that while the BEAM's fundamentals are incredible, the ecosystem and DX have major trade-offs depending on the application.
The Good Parts:
1. The BEAM's fault tolerance is real and it "just works."
2. The talent pool is a huge win—the engineers we've hired have been outstanding.
3. Tools like Oban and remote iex were absolute lifesavers for us.
Where We Struggled:
1. Ecosystem: Depth over Breadth. Phoenix, Ecto, and Oban are fantastic, but we often hit walls on things that would be trivial in other ecosystems, like a good Shopify library, forcing us to build our own.
2. The Full-Stack Problem: LiveView wasn't enough for our complex UI. So we had to adopt React anyway, which put us in a polyglot stack where, all things equal, a full-stack JS framework would have been simpler.
3. Developer Experience. This might be the biggest friction point. Compared to the instant feedback of Vite/TypeScript, Elixir felt slow. Autocomplete was inconsistent, and a 15-second recompile/test cycle on our large codebase killed momentum.
4. Deployment & DevOps: Elixir's clustering forced us into a more complex deployment (managing VMs with NixOS) because we couldn't use simpler container platforms like Cloud Run (we had to migrate off of fly.io due to its managed Postgres immaturity and observed general instability).
(Also one quick correction: hot code upgrades aren't practically supported by modern Elixir tooling, so it’s tough to count as a benefit.)
Ultimately, my take is that Elixir is a killer tool for specific problems, but for our full-stack app, it's not nearly as one-sided. I'm curious to hear if other teams have run into the same trade-offs: do you see them as fundamental issues or just a matter of ecosystem maturity? And if the latter, how are these improvements getting prioritized?
Thanks for compiling this. As a CTO running Elixir for 3 years (1 year of MVP deployed in production), my take is that while the BEAM's fundamentals are incredible, the ecosystem and DX have major trade-offs depending on the application.
The Good Parts:
1. The BEAM's fault tolerance is real and it "just works."
2. The talent pool is a huge win—the engineers we've hired have been outstanding.
3. Tools like Oban and remote iex were absolute lifesavers for us.
Where We Struggled:
1. Ecosystem: Depth over Breadth. Phoenix, Ecto, and Oban are fantastic, but we often hit walls on things that would be trivial in other ecosystems, like a good Shopify library, forcing us to build our own.
2. The Full-Stack Problem: LiveView wasn't enough for our complex UI. So we had to adopt React anyway, which put us in a polyglot stack where, all things equal, a full-stack JS framework would have been simpler.
3. Developer Experience. This might be the biggest friction point. Compared to the instant feedback of Vite/TypeScript, Elixir felt slow. Autocomplete was inconsistent, and a 15-second recompile/test cycle on our large codebase killed momentum.
4. Deployment & DevOps: Elixir's clustering forced us into a more complex deployment (managing VMs with NixOS) because we couldn't use simpler container platforms like Cloud Run (we had to migrate off of fly.io due to its managed Postgres immaturity and observed general instability).
(Also one quick correction: hot code upgrades aren't practically supported by modern Elixir tooling, so it’s tough to count as a benefit.)
I happened on this post that nails many of the areas for improvement that have also been painful for us: https://boredhacking.com/areas-of-improvement-for-elixir/
Ultimately, my take is that Elixir is a killer tool for specific problems, but for our full-stack app, it's not nearly as one-sided. I'm curious to hear if other teams have run into the same trade-offs: do you see them as fundamental issues or just a matter of ecosystem maturity? And if the latter, how are these improvements getting prioritized?