Yes, it’s always a surprise to me that, given how great Elixir is, it didn’t take over backend development. It seems so much better suited to doing something similar to microservices without a lot of the overhead you’d think people would love it. It always seems that fads win and projects with extremely tight concepts remain niche.
While Elixir is my current favorite language to hack in, it is very alien and downright hostile to integrating with existing systems. For example, relational database support was postgres focused for a long time (to the exclusion even of SQLite and continued inability to talk to Oracle). Then you have articles like https://dashbit.co/blog/you-may-not-need-redis-with-elixir pushing ETS over Redis. While it's a valid argument, it's not adoption-friendly.
Clojure brings about half the novelty of Elixir, runs on the JVM and still struggles to replace Java.
> Elixir abstracts that away and leaves a ruby-like language that hides much away - which good and fine.
Processes, message passing, and behaviours are all completely first class in Elixir. There's no hiding. `spawn` is `spawn`. `send` is `!`. `GenServer` is `gen_server`. `@behaviour` is `-behaviour(...)`. The entire Erlang stdlib is available directly.
We use processes, messages, and behaviours all the time in regular Elixir work.
Elixir adds a different syntax (note that I did not say better), a macro system, a protocol system, its own stdlib functionality, some better defaults, and a build tool.
It's perfectly fine and reasonable to prefer Erlang (I learned Erlang before I learned Elixir), but for the benefit of other readers, they are really not that different. The distance between Elixir and Erlang is very small. They could almost be seen as dialects.
I've been using Elixir for about a year on a side project and I've been enjoying it more than any other backend I've used (Node, Rails and C#). I recently discovered Ash and I feel like after that initial learning curve my productivity (and code quality) has improved quite a bit.
I wish Elixir had more mindshare beside just LiveView and "real time" type functionality. Even building a GraphQL/JSON endpoint without real-time requirements, the functional nature (no side effects), pattern matching and ruby inspired syntax makes writing plain old JSON controllers a joy.
While Elixir might not have a package for every use case under the sun, the low level primitives are there.
I've been wanting to learn Elixir for a long time but is it worth learning it without knowing Erlang first? I'm not against learning Erlang but just curious if Erlang is a good thing to know before tackling Elixir.
I have come to the simple conclusion that yeah if a tech is great and people are not launching products internally or as startups then maybe it's time to introspect.
if using elixir supposedly gives a competitive advantage, why aren't companies using to launch new products - both existing and startups.
a lot of those things quoted in the article are present on the jvm platform or through containers.
and btw some of those companies listed have migrated away from elixir e.g brex and discord.
I have a ton of respect for José Valim and the Elixir core team, I have to say: Elixir just doesn’t mesh well with the kind of infrastructure tooling that’s become standard today. The ecosystem has been growing impressively and there’s a lot to admire, but its philosophy often feels at odds with containerized, Kubernetes-based deployments.
Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly.
This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.
> 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!
It combines the "opinionated" aspects of ruby and rails and the power of erlang. The BEAM is like no other runtime and is incredibly fun to work with and powerful once you get how to use genservers and supervision trees.
We use Elixir for Mocha, and my one issue with it (I disagree with OP on this) is that live-view is not better than React for writing consumer grade frontends. I wish Phoenix took a much stronger integration with React approach, that would finalize it as the top choice for a web stack.
Am I the only one who never tried Elixir just because it has no strict typing?
Seems very hard for me to go back to a language with dynamic typing. Maybe I'm just wrong and I should give it a try.
Elixir's syntax is very intimidating. We maintain a fork of "bors-ng", I'd very much like to hack around a fix or two, but just stare at the code in awe.
One thing the author didn't mention is how incredibly polished the primary ecosystem of documentation, standard library, and tooling is. The Elixir standard library is incredibly consistent in order to support Elixir's piping operator, such that the first argument will basically always be the information you want passed from the function before it. In comparison, I frequently have to check the docs to confirm argument order on any lesser-used function in Python, Javascript, or C#. Then there's the fact that the second-layer of standard library, the OTP inherited from Erlang, which is expansive to the point of containing most things you'd want to do on a server. The documentation, in turn, is the gold standard that I (typically negatively) compare all other language docs to. It's organized, discoverable, and covers not just the "what" but the "How" and "Why" exceptionally well, not just at the function level, but the module layer as well. Frankly, only MDN comes close. All combined, it's just an incredibly productive language.
Hi! I recently tried to get into Elixir as an antidote to an acute javascript-fatigue...
To my surprise this there isn't really a good mobile story to build mobile apps for both Android and iOS with it, although it looks like it could be a great option for quick turnaround mobile apps with a web- or native frontend...
I know that there is something being worked on, eg. LiveView native: https://native.live/ , but that seems to target two entirely different frontend frameworks, one for each platform...
I started using capacitor as a wrapper for a HTML frontend, but I think I might potentially run into trouble when I'd try to move into production builds...
I think there's some space for research and maybe some nice starter packs / tutorials there... Because I think it is a big and pretty relevant market for browser-based apps, which Elixir seems to be very well suited to!
I'm grateful for any additional pointers, peace out! :)
Some don't use it because the performance on anything other than IO is just bad. This isn't just because its "not compiled", but because it has a scheduler taking up cycles and it enforces immutability, when can be brutal for some tasks when mutability can really speed things up.
I just started learning Elixir recently and I'm honestly loving it. Pattern matching is awesome and how it approaches concurrency and async work was so easy to wrap my head around. Pragmatic Studios has a great tutorial.
41 comments
[ 3.0 ms ] story [ 48.9 ms ] threadClojure brings about half the novelty of Elixir, runs on the JVM and still struggles to replace Java.
is there a popular pattern, perhaps as used by whatsapp, i guess?
It was never marketed that way though, and then Typescript took over which makes things even harder.
Elixir abstracts that away and leaves a ruby-like language that hides much away - which good and fine.
Erlang is by no means a simple language to get one’s head around.
Processes, message passing, and behaviours are all completely first class in Elixir. There's no hiding. `spawn` is `spawn`. `send` is `!`. `GenServer` is `gen_server`. `@behaviour` is `-behaviour(...)`. The entire Erlang stdlib is available directly.
We use processes, messages, and behaviours all the time in regular Elixir work.
Elixir adds a different syntax (note that I did not say better), a macro system, a protocol system, its own stdlib functionality, some better defaults, and a build tool.
It's perfectly fine and reasonable to prefer Erlang (I learned Erlang before I learned Elixir), but for the benefit of other readers, they are really not that different. The distance between Elixir and Erlang is very small. They could almost be seen as dialects.
I wish Elixir had more mindshare beside just LiveView and "real time" type functionality. Even building a GraphQL/JSON endpoint without real-time requirements, the functional nature (no side effects), pattern matching and ruby inspired syntax makes writing plain old JSON controllers a joy.
While Elixir might not have a package for every use case under the sun, the low level primitives are there.
if using elixir supposedly gives a competitive advantage, why aren't companies using to launch new products - both existing and startups.
a lot of those things quoted in the article are present on the jvm platform or through containers.
and btw some of those companies listed have migrated away from elixir e.g brex and discord.
Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly.
This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.
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!
It combines the "opinionated" aspects of ruby and rails and the power of erlang. The BEAM is like no other runtime and is incredibly fun to work with and powerful once you get how to use genservers and supervision trees.
We use Elixir for Mocha, and my one issue with it (I disagree with OP on this) is that live-view is not better than React for writing consumer grade frontends. I wish Phoenix took a much stronger integration with React approach, that would finalize it as the top choice for a web stack.
I decided to learn Clojure for my next language.
To my surprise this there isn't really a good mobile story to build mobile apps for both Android and iOS with it, although it looks like it could be a great option for quick turnaround mobile apps with a web- or native frontend...
I know that there is something being worked on, eg. LiveView native: https://native.live/ , but that seems to target two entirely different frontend frameworks, one for each platform...
I started using capacitor as a wrapper for a HTML frontend, but I think I might potentially run into trouble when I'd try to move into production builds...
I think there's some space for research and maybe some nice starter packs / tutorials there... Because I think it is a big and pretty relevant market for browser-based apps, which Elixir seems to be very well suited to!
I'm grateful for any additional pointers, peace out! :)
Why nobody's hiring for Elixir :(
How Elixir Powers the BBC From PoC to Production at Scale - Ettore Berardi | ElixirConf EU 2025 https://www.youtube.com/watch?v=e99QDd0_C20&ab_channel=CodeS...