You use the phrase twice in the article. Could I ask you to put an asterisk by the first one too?

(I came across it, stopped reading the article to Google it, couldn't find it so came to HN to search the comments and then went back to the article and saw the asterisk later on)

if the author is reading this a minor edit should be that whatsapp uses erlang, not elixir.

> For those I managed to confuse, “glass-to-tin” just means “front-to-back” or “from the screen to the back end”.

So like a thin mirror? Which only serves to show the viewer back to themselves? And which also consists of just two extremely simple parts, that is, two panes/sheets of uniform materials, and nothing more?

How do you even come up with this metaphor for a web-based application? It's horrible!

> 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

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?