Ask HN: Why isn't Phoenix/Elixir more mainstream?

The fact that Erlang and Elixir do not have static typing, outside of a voluntary type checker, makes me worry about using them. And yes, the approach to error handling in Erlang and Elixir is "let it crash" etc. The runtime debugging tools are excellent. There's approaches to design which ensure that even if there's some serious bug, you can still recover with minimal service loss except when your bug is something which automated testing should have caught but at this point I just feel: "Why deal with all that if you can have high quality static typing prevent you from having to deal with that in the first place?"

I can think of a few reasons why this stack might not be more popular:

1. Many of Elixir's historic strength's involve applications similar to Discord, where you have complex webs of near real-time communication between users implemented by a distributed back end. But very few apps actually need this.

2. LiveView offers a second compelling use case: single-page apps (SPA) that don't need to worry about client/server data sync. It's a surprisingly great environment to throw together a SPA very quickly. But LiveView is really new, and the first book on it is still in "beta."

3. Elixir is basically a purely functional infix Lisp2 with pattern matching and Erlang-style parallelism. With a half-baked type system via Dialyzer. It's a delightful language, but this sort of combo is a bit niche. Where I live, I can find Rust programmers more easily than Elixir programmers, for example.

4. Actually getting a dev environment installed and working currently requires reading bug trackers. The VS Code plugin, for example, currently goes into a crash loop if your shell is anything but bash or zsh, IIRC. One you get the tooling working, I'd say most of it compares very favorably to npm or Python. Elixir is trying to have an amazing ecosystem, but there are still rough edges.

The sweet spot here would be something like, "We have just a couple of senior programmers, and we want to develop a SPA really quickly, with no frontend/backend split, and faster iteration speed than more people's React stacks." And it's a bonus if your app can actually exploit Erlang's message passing or distributed programming features.

Something where you needed to keep many different user's SPA pages in near-instant sync? It would rock.

Rust can be massively concurrent without Actors and GenServers.

So while the Actor model / let it fail approach changed the way I think, at the end of the day I found the traditional paradigms to actually be faster and cleaner to the real world applications that made me money.

For hires that already know Elixir, I've found the talent pool to be way above the average (and expensive). They're usually senior devs that fell in love with Elixir, wanting to move away from their previous tech stacks or have already worked at an Elixir shop.

[0] https://elixir-lang.org/getting-started/processes.html

I don't agree at all... tRPC/Prisma have been a joy to work with. We still use a traditional SPA app.