Why isn't Phoenix/Elixir more mainstream?

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 capability compared to alternatives (Ruby+Rails, Python).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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). The deployment story for Elixir was a pain when I was looking into it, vs. Golang which is just a binary, so that’s another thing working against it, but this was in 2017.

I also think Elixir is really refreshing as long as you stay within the bounds of what you can look up easily on Google. Once you step out of what’s readily available it becomes _immensely_ more difficult. 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, so that felt awful.

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

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

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.

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 all 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; while 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. 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.

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! 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 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've been experimenting with Elixir lately. Phoenix LiveView, in particular, is a fantastic technology.

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.

Honestly, after years of writing python I have now gotten to a point where I fear dynamic typing.

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?"

We have switched to Elixir and Phoenix as our go to stack gradually over the last 5 years. We've found that LiveView in particular, with it's ability to avoid a separate front-end framework altogether, has let us deliver applications to clients in a significantly more productive way. We were a rails shop back in the day, and were able to build things very quickly. When the whole front-end framework thing got big, it slowed us down a lot because we were building two applications, essentially. Now that we are able to go fast again we (and our clients) are enjoying things a lot more.

I should also say that if you do need to use a separate front-end for whatever reason, I've built a thing called LiveState: https://github.com/launchscout/live_state that lets you keep things far simpler and gives a "LiveView like" experience.

Oh, and as far as the "shortage of Elixir developers". Unfortunately with layoffs in the startup community it's probably easy to hire just now. Even when that was not the case, we've had great success with brand new apprentices picking up the language and being productive very quickly. We recently had an apprentice go from brand-new to keynoting Elixirconf in two years. She is super amazing, but still, other apprentices have also done very well.

for me its hard to justify betting on something without a compelling edge computing (eg cf workers) story in 2023. i could not even think of a case where beam would be the right fit for a webapp/webpage except maybe a static rendered status page for something that runs on beam anyways. and i say this as a diehard erlang fan who would love to have a justification to use it more. of course there are plenty of services/ systems where beam is godsend but nothing that would fit phoenix’s target.

There are a few factors.

Most devs are trained in OO approaches so you have to learn to think about problems from a functional perspective. While a lot of people believe that the functional approach is a huge win (myself included), asking developers to both use a different language AND think about problems differently is a leap.

Truth be told, I was blissfully ignorant of how many concurrency issues non-BEAM languages truly have until I learned Elixir. Now I can't unsee them.

While there are a lot of polyglot devs out there who are happy to utilize a different language for its strengths, there are also a lot of developers and companies who are both time and emotionally invested in their language of choice. It's not exclusive to a particular language, it happens everywhere.

One of the unfortunate things that accompany languages that are able to do more with less, is that the companies which succeed with them...need fewer developers. There are a lot of hugely successful companies using Ruby on Rails, just as an example. Even today, you will see people fight tooth and nail against using it either because: A) They want to use their stack of choice or B) They don't understand why it's a better choice for the job.

In language terms, you win developer eyeballs with 1 easily quantifiable thing...benchmarks. X is faster than Y in benchmarks, a lot of developers will want to use X.

Quantifying productivity is harder (Ruby). Quantifying advantages of concurrency, clustering, heap isolation, maintainability with very high productivity is harder (BEAM). Benchmarks are easy.

Widely adopted language selling points as a comparison for what Elixir is up against:

- Java is taught in schools, heavily adopted in enterprise, portable, fast. It's okay at everything.

- Python is taught in schools, installed by default on Linux. It's okay at everything.

- Javascript is the only language available in browsers and has a selling point of using the same language on the client and server. Widely adopted despite a huge chunk of people who hate it.

- .NET gets the entire backing of Microsoft, usage on Windows and a natural selling point with the various Windows shops out there. It's widely useful on those platforms and has an invested and certified following.

- Apple languages are similar to .NET selling points.

- Go is portable, pretty fast has a low learning curve, fast compiler (productivity win) and the closest concurrency model to the BEAM as well as backing of Google which lets execs rest easy.

I can definitely make a case for why Elixir is a better choice for most of the things you'd use these language for, except mobile apps. But even then, there is going to be an argument. People will defend their choices and you won't see much progress. And somebody will ask for a benchmark, which Elixir won't win because it's not designed to win straight line benchmarks.

I feel it's because the main draw of Erlang/Elixir and the BEAM, was scalability. Since the time Elixir was introduced, the Cloud system vendors have developed many solid alternative answers to the scalability question, with products that don't even require developers to learn a new language.

The soft-realtime and failover concepts that Erlang/Elixir champions are still features that are unmatched elsewhere though. I have less experience with Phoenix, but writing a WebSocket server in Elixir with Erlang's Cowboy feels like the best possible way to write a WebSocket server. In fact, in that context (which is admittedly narrow), I think Elixir might be the best possible tool available for WebSocket server programming. Even if it's only used on a single machine.

I also see the Elixir team making efforts to push into the ML space. If they can develop a user friendly solution to Distributed Model Training, based on OTP semantics, I can imagine Elixir pulling some attention away from Python.

But tbf, to get the most out of the Elixir, you need to learn a little about OTP, which is very different. In fact, while I won't go as far to say learning Erlang is a prerequisite to learning Elixir, it helps alot, and that can be intimidating.

And if you're doing webdev work, then Elixir would mean that you also have to manage / maintain your own servers too. Then there's the niche status of all BEAM languages, but that's the 'network effect' I guess.

i don't find all-in-one frameworks attractive at all.

the frontend/backend split is the easiest way to separate concerns, and ever since the first frontend frameworks i never wanted to go back to the old way of having them integrated.

the pros of keeping them separate are that i can often reuse the backend for multiple applications/websites, or replace the frontend while keeping the backend, and inversely, i can replace the backend if needed without changing the frontend, and therefore without affecting the user experience. i find this flexibility invaluable.

i also prefer to write frontend code in native javascript, although that depends on how well the transpiler/framework works in helping me find errors browser errors in the original code.

I was a strong Elixir shill for years. I still use it in personal projects (it's very fun) but commercially it never replaced Ruby for me. Here's my quick take:

1) There wasn't large enough gap from typical business perspective that needed to be filled by Elixir.

2) No really big company marketed Elixir. People start shoving microservices/Kubernetes/whatever new tech into any simplest app because Facebook does it. Had it been different, I believe Elixir would explode in popularity.

People here mention that Elixir means higher pay for devs but it was never the case for me. For every Phoenix role there were 5 better paid RoR/Fullstack ones. If I've proven empirically that I can provide value with RoR, why switch? I can derive joy from it by using it on my own project, and from the fact that it's much more fun using any lang on hobby projects than commercial ones.

Do we have a serious contender for ActiveAdmin in Elixir yet?

No matter if the language is Great or bottom line worse if there’s no ecosystem and libraries to promote productivity is all moo, hey we hate JavaScript but before I think of wasm I would have written most of what I want in JavaScript, this is why Go was so productive that it took just 5 years since it’s creation for the software tech world to feel the impact, that’s why rust ecosystem pushing for more high level library sugaring or “one click convenient macros” and I kinda like where ocaml is going it really needs to remove the tag “Jane street programming language”

> Why isn't Phoenix/Elixir more mainstream?

Very simply. It hasn't been adopted by a giant tech corporation as one of its main languages. All the startups that do use it aren't the size of Google or Microsoft.

Thats not to say it's not a wonderful language.

The frameworks and libs are top notch.

Elixir developers tend to be polyglots and very good engineers.

I know of plenty of small companies who did start off with elixir because they could do so much with a single language across multiple domains, with fewer engineers and lower server costs.

I think the learning curve is one of the biggest challenges. Functional programming is very different for someone who got started with JS/Python/PHP/Java/C#/Ruby/etc. and you have to re-think how you do things.

And when you get a bit further in, since there’s no classes and inheritance in Elixir, you have to get into macros or other really complicated patterns if you want to avoid code duplication.

So while I love the language, it is a challenge that I you can’t use the patterns you’re used to from other languages, but have to learn new (arguably better) ways to do things. And not everyone wants to be challenged this way.