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?
matthewsinclair•7mo ago
I'm curious about the areas you've struggled with, particularly number 3.
I have found the DevX to be particularly great and one of the strongest aspects of Elixir. I abhor JS as a language (I know, I know, I'm fully aware of my biases!), and the tooling and complexity therein are infuriating. I find React and JS, in general, so impenetrable that it has stopped me from making progress with front-end development. However, with Elixir/Phoenix/LiveView, I have created a more-than-credible web front end that would have otherwise taken a React-based team weeks, if not months, more time and complexity. I also haven't seen the kind of recompile problem you mention, as HEEX changes are reflected immediately in the browser on save (at least in my setup).
I do take your point on Fly.io, tho. I am currently operating at a very small scale, and I have been experiencing regular uptime issues. I'm in the process of working out what to do about that as I scale.
Thanks for taking the time for that considered and nuanced response. Much appreciated!
ryanrasti•7mo ago
> I'm curious about the areas you've struggled with, particularly number 3.
At the beginning things were very quick like your experiences. It's when we built up a larger code-base (we're currently at ~100K Elixir LoC -- excluding tests) over the last three years, that making a change in a file triggered hundreds of other files to recompile and that cycle took ~10s on modern machines.
> I abhor JS as a language (I know, I know, I'm fully aware of my biases!),
Yeah I hear you. What changed my mind was actually TypeScript -- it's the most advanced (and approachable) type system I've worked with. Take a look at the GIF here: https://kysely.dev/ -- all of the auto-completion is powered by TypeScript.
> However, with Elixir/Phoenix/LiveView, I have created a more-than-credible web front end that would have otherwise taken a React-based team weeks, if not months, more time and complexity.
It's hard to gauge. My assumption is that the big gains would come from having a single language framework (e.g., Phoenix/LiveView vs. Node/React).
> I do take your point on Fly.io, tho. I am currently operating at a very small scale, and I have been experiencing regular uptime issues. I'm in the process of working out what to do about that as I scale.
FWIW we haven't had any issues after migrating to GCP -- even though the setup is more hands-on (VMs). I'm not sure there are other turnkey robust solutions if you want clustering.
I think the last big unknown will be the entire AI aspect of things. I see competing possibilities:
1. AI enables faster development for Elixir & ecosystem -- allowing them to e.g., address issues faster and shine more clearly
2. AI accelerates consolidation and before you know it every new project is fullstack NextJS and old projects are re-written to migrate onto it
Perhaps the most important will be feedback to the LLM (e.g., in the form of static analysis and running tests) -- TypeScript has a huge advantage here IMO. We got to a place where we had basically no runtime type issues (e.g., NPE, exceptions/crashing of FE) in our startup with TS on the FE. Have only heard of similar stories in cases in more niche FP languages like Elm
matthewsinclair•7mo ago
I won't comment on TypeScript (other than to bemoan its JavaScript origins), but for what it's worth, people I hold in high esteem have a lot of good things to say about it.
But as far as LLM-assisted coding goes, the pure functional / no-side effects / immutable data properties of Elixir (and to be fair, other functional languages that owe their ancestry, in part, to Lisp) seem to have a big impact on the LLM's ability to reason about change. At least that is my experience with it over the last 6 months or so.
It's such a fun time to get the opportunity to muck around with these technologies, "programming" is _profoundly_ changing under their influence.
ryanrasti•7mo ago
Yeah good point re: functional programming and reasoning.
When there's no global mutable state you only need generally need a smaller context to figure out what's going on. I imagine it's the same for LLMs.
ryanrasti•7mo ago
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?
matthewsinclair•7mo ago
I have found the DevX to be particularly great and one of the strongest aspects of Elixir. I abhor JS as a language (I know, I know, I'm fully aware of my biases!), and the tooling and complexity therein are infuriating. I find React and JS, in general, so impenetrable that it has stopped me from making progress with front-end development. However, with Elixir/Phoenix/LiveView, I have created a more-than-credible web front end that would have otherwise taken a React-based team weeks, if not months, more time and complexity. I also haven't seen the kind of recompile problem you mention, as HEEX changes are reflected immediately in the browser on save (at least in my setup).
I do take your point on Fly.io, tho. I am currently operating at a very small scale, and I have been experiencing regular uptime issues. I'm in the process of working out what to do about that as I scale.
Thanks for taking the time for that considered and nuanced response. Much appreciated!
ryanrasti•7mo ago
At the beginning things were very quick like your experiences. It's when we built up a larger code-base (we're currently at ~100K Elixir LoC -- excluding tests) over the last three years, that making a change in a file triggered hundreds of other files to recompile and that cycle took ~10s on modern machines.
> I abhor JS as a language (I know, I know, I'm fully aware of my biases!),
Yeah I hear you. What changed my mind was actually TypeScript -- it's the most advanced (and approachable) type system I've worked with. Take a look at the GIF here: https://kysely.dev/ -- all of the auto-completion is powered by TypeScript.
> However, with Elixir/Phoenix/LiveView, I have created a more-than-credible web front end that would have otherwise taken a React-based team weeks, if not months, more time and complexity.
It's hard to gauge. My assumption is that the big gains would come from having a single language framework (e.g., Phoenix/LiveView vs. Node/React).
> I do take your point on Fly.io, tho. I am currently operating at a very small scale, and I have been experiencing regular uptime issues. I'm in the process of working out what to do about that as I scale.
FWIW we haven't had any issues after migrating to GCP -- even though the setup is more hands-on (VMs). I'm not sure there are other turnkey robust solutions if you want clustering.
I think the last big unknown will be the entire AI aspect of things. I see competing possibilities: 1. AI enables faster development for Elixir & ecosystem -- allowing them to e.g., address issues faster and shine more clearly 2. AI accelerates consolidation and before you know it every new project is fullstack NextJS and old projects are re-written to migrate onto it
Perhaps the most important will be feedback to the LLM (e.g., in the form of static analysis and running tests) -- TypeScript has a huge advantage here IMO. We got to a place where we had basically no runtime type issues (e.g., NPE, exceptions/crashing of FE) in our startup with TS on the FE. Have only heard of similar stories in cases in more niche FP languages like Elm
matthewsinclair•7mo ago
But as far as LLM-assisted coding goes, the pure functional / no-side effects / immutable data properties of Elixir (and to be fair, other functional languages that owe their ancestry, in part, to Lisp) seem to have a big impact on the LLM's ability to reason about change. At least that is my experience with it over the last 6 months or so.
It's such a fun time to get the opportunity to muck around with these technologies, "programming" is _profoundly_ changing under their influence.
ryanrasti•7mo ago
When there's no global mutable state you only need generally need a smaller context to figure out what's going on. I imagine it's the same for LLMs.