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

[1] https://hexdocs.pm/phoenix/overview.html

However, in 2023 rather than the 2013 I wrote that in, I'd add something else. In 2005, BEAM was revolutionary. It had things nobody else had. In 2023, it's a nicely integrated collection of a bunch of features you can get almost everywhere else, plus some features that aren't actually that important anymore because there are other solutions to the problems, even if they aren't the Erlang solutions... and most of those features are now distinctly second best.

Second best performance. Second best isolation story; we have ways of isolating things, both through convention, and with things like Rust, that don't require full immutability and the serious impact on day-to-day coding it brings. Second best messaging platform; the BEAM message bus is highly language-specific, unlike SQS, Kafka, etc., and it chose 0-or-1 where 1-or-many has been over time revealed to be generally preferable as a default. OTP is nifty, but where the Erlang community believes it must be implemented to the letter, with every jot and tittle and minor bit of functionality copied to be of any use whatsoever, in most cases it turns out some internal watchdogs + some sort of systemd-like restart (or docker, or k8s, or...) gets the job done just fine; in this case Erlang is best-of-breed, but the second-best solutions offered elsewhere do the job and the price you pay to fit into that best-of-breed can itself be an impediment at times. (Not everything can be structured as a whole bunch of relatively small communicating processes... though, admittedly, quite a bit more than many programmers may expect!) Second-best type system; I understand why BEAM's types are structured like they are [1], but after a lot of experience, the static type world has figured out to have both static types and upgradability, if that's what you need. Other features, while nifty, like process restarts with new code, just turn out to be more niche than the brochure may advertise. That's a super important feature for phone switches, yes, absolutely, but it's never actually been something I need, and that despite the fact I've done "real network code" beyond just web APIs. It's not like Erlang made my deploy process go away, it just made it different, and I don't miss not having hot restarts in practice. And I could continue on for some more features, I think I made the point though.

I also suspect the BEAM stack has a very leaky bucket now. Yes, there's definitely people who pick it up and find it very impressive, but I also expect there's a lot of people who pick it up, perhaps with a bit more experience in even one of the spaces BEAM plays in, and notice that the solutions are second best and they need something it doesn't provide well, and quietly put it back down again without putting up blog posts. For instance, if you're already hooking up to a cloud message bus and using k8s or something to run a cloud of lots of small instances, you are, frankly, 80% of the way to Erlang already, in most of the ways that count, so switching to Erlang generally comes with all the disadvantages that switching to any language would entail while not bringing all that much to the table to compensate for it. Likewise, are you heavy into serverless? It may be a completely different solution, but it leaves nothing much in the problem space for Erlang. You no longer have the problems Erlang was meant to solve. (You have different problems.)

So, I'm answering the question "why isn't it more popular", not "why does it suck". That's because it doesn't "suck". It's a fine and viable solution to many problems. While I am critical of the now-second-best nature of many of its features, the integration itself is a feature that very few other platforms can compare with! While I can find every feature now in other languages and environments, I will be putting together a stack of my own somehow, which can be beneficial, but is also definitely a cost of its own too. But other than that, BEAM doesn't bring much special to the table anymore. It is very easy to put together a stack in many other languages that exceed it in one or more dimensions, and those are often the dimensions you care about a lot (performance, static type safety, language-agnostic message busses for heterogenous deployments, there are languages/runtimes now better than even BEAM at managing tens/hundreds of thousands of simultaneous connections now... any of these can easily be a determinative factor). But its bucket has a thousand little cuts in it for the water to leak out of. No one big gash by any means, but a lot of little holes.

[1]: https://news.ycombinator.com/item?id=37261154

I think PGs advice really depends on the founding team. Now it’s quite common to have only semi technical founders that make an engineering hire instead of the founder being an engineer, because languages like Python and JavaScript have commoditized the initial CRUD aspects of launching a product.

If your product is more technical and low level it makes sense, but if your building a HTTP SaaS app that connects to a database then chances are the difficulties and differentiation happen on the Product/Design level, and much less so on the engineering level unless you make it big.

Haven't you just contradicted yourself there? That's two different languages and two different stacks.

Ironically if you were using Elixir the default would be to use Liveview so you'd use a single language.