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

I worked with a team that was convinced of the superiority of elixir/erlang over ruby/rails in our ecosystem. It can accept thousands of simultaneous connections, etc. But the devil is in the details. If those connections include queries to a database then it's just a slow and clunky as every other front end framework and the learning curve is pretty damn steep. So overall the lack of integration with existing tooling and communities is what drove us away. Sure, you can do magnificent things if you keep every little bit in process but it's really hard to do that. And you need a super big box to make sure that everything is in one process.

Because Elixir is a language with a fundamentally different paradigm when it comes to state and concurrency, similar to how MLs like Haskell or Rust are different then just picking up and writing some JavaScript or Python. It's different, so it's not mainstream. I think that's really the thrust of it.

I made a fair amount of money with Phoenix and Elixir and I like them.

My take is that what's hindering their further expansion to mainstream are: Elixir is not curly braced and it's not object oriented. Those two alone make a big difference in familiarity. The vast majority of developers are using curly braced OO languages and it takes less effort to learn another one. I was coming mostly from Ruby and Elixir was designed with a syntax and module names similar to Ruby's.

That GenServers are objects with methods and an internal state is another, possibly ironical, matter.

n=1 but over my 15 year career I've tried picking up elixir and found it too difficult to learn. I found the syntax hard to read and felt I had to spend 2x more time digesting a similar method than in scala/java (my background). I wish I had picked it up though, being a consultant in elixir seems lucrative and I've received multiple offers to maintain a phoenix/elixir codebase at $150/hr.

The trend right now is AI, which is mostly written in Python. Most people want to write their whole stack in 1 language, whenever possible. So people just default to Python servers and React clients.

There is tooling like Carton being developed to work around this, but the gravity is always towards monolanguage stacks. In the past the incumbent would get stiff and lose resiliency, like Java or C. That's when a shiny new language like Python would come along. But with Python's governance and community it seems performance issues (Mojo) and developer experience (PEPs) are still improving. Python seems to still have sticking power.

These things take time. Do you expect such a new language to be adopted by 90% of developers?

Elixir 1.0 was released 9 years ago. Most people use C, Python, Java which have been around for 30+ years. I use Elixir full time but I know I'm on the bleeding edge compared to the vast majority of developers, let alone corporations which operate and change over longer timescales, and Elixir is a major paradigm shift compared to pretty much any other language. A C shop might plan to move to Rust, but Elixir is a completely another universe.

A much more interesting question is why didn't Erlang get much of a foothold in the industry. The fact that you are asking this question today means that Elixir has been instrumental in putting Erlang/OTP in the conversation, so its usage might finally start to grow thanks to a simpler syntax, healthier ecosystem and, most importantly, a lot of commercial interest.

For a technology to become widely used it usually needs one or more of these factors when it is released:

1. A big company that adopted it in a major way or created it (Go, Java, React).

2. A very low barrier to entry (Go, node.js, Python).

3. A major leap in productivity compared to alternatives (Ruby+Rails, Python).

The sad answer is that it's because it's not familiar to most programmers. The quality of the tools sadly has barely any bearing on their adoption.

It's just too different and too advanced for the average programmer to use. There is no surprise that we have languages like Go now - explicitly familiar, explicitly dumb.

Elixir does not have familiar C-like syntax or the usual OO-ish programming model, and its (btw fantastic) approach to concurrency is also very strange to people coming from popular languages.

Here is why I think it's not more mainstream

1. The really cool and differentiated aspects of elixir require specialized deployments. Cloud vendors are optimized for stateless horizontally scalable infrastructure not stateful infrastructure.

2. Elixir is a functional programming language and this means you cannot mutate variables. While I like many aspects of elixir, not being able to mutate state makes elixir unsuitable for any task that cares about performance at all. Many algorithms are memory bound and you really cannot justify using things like linked lists.

I think a few things are happening.

First, the language paradigm pendulum seems to be swinging back towards the middle.

Second, and perhaps more impactful, Ruby on Rails is having a bit of a renaissance.

In addition to what others have said...

There are enough other acceptable languages+frameworks, and two of them (Python and JavaScript) are unfortunately just too visible and in the way.

Students, junior developers, and developers from non-CS backgrounds start with what's "easy" and available and talked about (lots of published examples, guides, etc.)

Elixir is for those who have experienced other langauges and seek something better. And since it definitely requires a paradigm shift in thinking (OOP->Functional), that puts it essentially behind a fence for many people. Why climb over the fence if Python is "good enough".

Elixir also has a great story with BEAM and all the amazing capabilities it offers, but those are capabilities that would be desired and exercised by experienced developers.

Ultimately it's a matter of mindshare. Search for programming examples for just about any topic, and you're going to get a flood of Python or JavaScript results. Maybe Java too. This is especially true since some of the programmer-mills appear to require students to regularly post blogs with trivial or lightweight essays and examples in the aforementioned languages.

The people who use real power tools are usually busy doing real things, so they generate less web fluff about their tools.

Adoption of new programming languages is always an uphill struggle. The majority of companies will exercise a lot of caution around their technology stack because they are anticipating (rightly or wrongly) difficulties hiring staff who can work with the programming language.

I think this causes a big push towards adoption of a already popular tools, until those popular tools cause significant issues. There's a weird kind of loop there where "it's not used much" is the reason something isn't used much but those cycles can be pretty tough to break.

biggest pro: elixir is built on erlang. Erlang was made to have incredible multithread performance distributing messages on computers from decades ago.

All those scaling problems Mastodon admins complain about? 99% of wouldn't exist if they were using one of the Phoenix based fediverse apps instead of the Rails based one (mastodon). Sure, some of the larger instances would still have issues but most folks would get plenty of throughput on one average machine.

Erlang's a great language. Once you wrap your head around the fact that = is a "match" operator and not an assignment operator... ;)

My day job is as a back-end rails dev, but I was introduced to Phoenix by a couple of the most prominent folks in that community. It is my belief that Elixir and Phoenix are unquestionably a better choice than Rails for new work. The only reasons to use Rails instead are that ruby has a bigger ecosystem of libraries, and none of your staff knows Elixir. Alternately that you're a ruby dev who's just whipping out something quick and performance doesn't, and won't, matter.

It's not really filling a void.

Rails and Python have a answer to the same issue, and more libraries available to them.

Also. (and I spend 90% of my time as a paid elixir dev). It's an ugly language that makes you roll your own on so much. Migrations require you change the schemas, and you have schema modules and access modules.

The elixir docs are a mess of assumptions and there's no consistency. The number of times I have to Enum.into(%{}) after doing something with a map. Oh.. And Enum.map returns a list which is not an array but is represented in the language as an array..

Also.. With many JS libs don't embrace the many small calls to get data, so the OTP/threading side of elixir (Which is awesome) is almost never called on. Bigger calls are favoured, and elixir isn't great at this (or well no better than rails)

On the whole, I'd say the benefits of using elixir are never realised, but the cost of using elixir is paid regardless.

I have been a big advocate for Elixir for 5 years before switching off.

My takeaways: love José Valim and the team and the libs they produce. The team is always humble and helpful and produces high quality content in both code and documentation.

Why I stopped using Elixir: I was using Elixir obsessively as a performance chasing tool, but then it just didn’t fill the gap properly:

1. Python (or other massively used language) is preferred for large SaaS apps where performance doesn’t matter. As an engineering manager, I can go out and hire a huge team instantly for Python.

2. Rust is much faster and not super difficult. When I ran out of optimizations for Elixir I found myself dropping down to Rust. Then asked myself why even use Elixir?

With those two points, Elixir, like Haskell, changed my programming mindset immensely, but as a professional context, quite frankly you have to use what you can build a team with. Elixir has very few engineers to source from.

Because there’s very little competitive advantages in programming languages (from a technical perspective)

I'm not super experienced with Elixir/Phoenix, but I did notice the documentation was rather disappointing when I tried to learn it, compared to Rust. I kept trying to find a tutorial for a basic web app with Phoenix, everything I could find was for an older version which wasn't compatible with/had different names and locations for the various files than the version I had. Kinda blocked me from getting more into it.

I tried to learn it, but to me it just looks like if a crackhead wanted to create his own version of PERL.

The code is unreadable.

Then why would I use it if I can do the same things in Go or Python with much more sane syntax.

Network effects and platform consolidation. Its not mainstream because its not mainstream.

Single data point:

I spent a few hours following a couple of different (Phoenix) "getting started" guides earlier this year. Nether of them "got me started", but instead into a semi-installed broken state unable to progress without delving into other docs/stackoverflow/etc.

I am no longer in my twenties, I have no patience with that, I take it as a sign that the tech is still for enthusiasts only and I should take another look in a couple more years.

If I was being paid to learn it, I'd persevere, but I was simply curious so I'll wait for others to smooth off the rough edges.

[dead]

Pros:

1. Clear and readable code. Emphasis on pure data being passed around.

2. More minimalist. JavaScript stacks like T3 app (Next.js, TypeScript, tRPC, Prisma) feel like they're solving endless problems caused by other "solutions" in the stack. With Phoenix, you mostly write Elixir, some Ecto macros, sometimes JavaScript for edge cases.

3. Phoenix LiveView is amazingly intuitive

4. Way faster to prototype in, more time in "flow"

Cons:

1. Fewer UI components to pull from if you want to do something complex with the frontend

2. Not a big fan of Ecto macros

3. Have to figure things out yourself (usually read from docs or source code). Difficult for newcomers because of the lack of guides, but good for experienced devs

I agree with others that the Getting Started material isn’t great and documentation in general is a struggle sometimes. It’s also a “chicken and egg” problem: the smaller size of the community means sometimes community packages are not available or appear abandoned, which in turn scares off adopters.

Stepping back from all that though, what I will say is that Phoenix itself, LiveView, Erlang concepts like GenServer, the community’s willingness to help, and the language itself - all FANTASTIC.

Anecdotally, I think Elixir/Erlang are too difficult/esoteric compared to other languages. That makes it hard to come back to after not touching it for a while, which means it'll be incompatible with a lot of devs that use other languages. When I come back to Golang, I can pick it up almost immediately, so I often use it for personal projects. It also has great concurrency primitives, which is one of Elixir's biggest selling points.

Where does that leave Elixir then? It's too difficult to come back to easily, plus it's too different from other languages, and it _feels_ like it doesn't necessarily do anything better than Golang, even if it does (I know it does). This makes it hard to justify the cognitive overhead.

I also think Elixir is really refreshing as long as you stay within the bounds of what you can easily look up online. Once you step out of what’s readily available it becomes _immensely_ more difficult relative to other languages. Last I used it I was also frustrated with the amount of times I had to drop into some Erlang bits to use a library, and the Erlang things it keeps were also hard to wrap my head around (why are GenServers named Genservers? Name it literally anything else)

For all of those reasons I just haven't been able to go back to Elixir. Its model of programming is just too esoteric and different for me to be able to integrate it into my stack.

I wrote this for Erlang about 10 years ago, and it probably still holds water: https://news.ycombinator.com/item?id=7277957

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 integ...