I've been a frontend developer for years, primarily working with React and Vue, connecting them to REST or GraphQL APIs. Lately, I've been diving into Phoenix/Elixir, and I've been intrigued.
From the docs and examples, Phoenix seems to offer a significant amount of built-in functionality, potentially providing a more streamlined and robust approach than the separate backend/frontend architectures I've been using.
However, I know there's always more to the story. For those experienced with Phoenix/Elixir:
What are its pros and cons compared to popular frontend frameworks?
Why hasn't it gained as much traction as other frameworks?
Appreciate your insights!
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.
That's a cop out excuse. On the Discord, Slack, and Elixir forums, there are hundreds, if not thousands of devs looking for work.
Often it is lamented that nobody can find enough Elixir engineers, but they also seem to have a very hidden agenda here. Executives just want the job done, and Elixir can do it, but all too often the trope of not finding enough resources is lauded about as a reason to stick to LANGUAGE_MANAGE_HEARS_ABOUT_MOST (Python, JS, RoR, et al).
Everyone also only wants Super-senior-staff-principal engineers for Elixir roles, with 20 years experience, and can live code a project to perfection in 3 hours. Maybe realize that as the community grows and engineers adopt to the language, it's ok to bring in early-careerist resources, or others who just are getting started out. Give them a book, some assistance, and keep working with them, and it doesn't matter who knows it at first, in 6 months you'll have a rockstar team.
If you're a savvy dev and a search like:
https://www.itjobswatch.co.uk/default.aspx?q=Elixir%2C+Rust%...
comes up with zero for Elixir, you don't sink time into it.
If nothing else, you know that the low job availability puts you in a very weak bargaining position.
For perf optimisations, you have Ports or NIFs (irc), where Ports are just knowingly volatile processes, and NIFs are FFIs, which is an almost universal feature across all languages.
But I suppose your experience is based on use case. And I would agree that commercial BEAM language experience is generally thin on the ground, if you're role is to build an engineering team (though I can't imagine Rust expertise being that much more abundant either).
One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards. But ignoring that (especially with vendor lock in issues), I often wonder why Elixir hadn't put a larger dent in the popularity of Kubernetes. Because BEAM's approach to managing multiple services across machines seems both much more powerful, and dev friendly.
IMO, that's a misconception. They work at different levels and I wrote a more in-depth explanation here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
Although I agree the sentiment plays a role on adoption, because many ask "why Elixir when I have k8s", while in practice, if you like k8s, you should enjoy Erlang/Elixir. They apply similar principles at different scales.
So I don't think we could have made a dent on k8s, but rather, we should have positioned ourselves earlier within k8s strengths. :)
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.
http://www.paulgraham.com/pypar.html
Sadly, the culture of programming language choice in commercial contexts has changed a lot in twenty years, but you can replace python with rust or elixir because programming language choice is a good proxy to understanding insight, intuition, and intelligence.
I like python, but if the broad preference mattered, we'd all be running J2EE apps today. My reasons for choosing python around Y2K were as philosophical then as they are now.
Where your argument goes awry is that what matters is how the programming language catalyzes better interdisciplinary team communication. Code tells a story that, the easier it is to read, the clearer the story gets, and that pays unforeseen dividends in development, deployment, debugging, and distribution.
Computer optimization is straightforward by comparison to scaling human commercial endeavors.
“Programs are meant to be read by humans and only incidentally for computers to execute.”
― Donald Knuth
Programs are meant to be read by humans. Which is why Python and the bunch are so widely popular across foreign contexts.
Elixir is hard in that context because it introduces a lot of paradigms.
I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.
There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.
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.
Like you said it’s mostly senior expensive engineers. They are really good, but is it worth it? Do 90% of startups need it? I have had success hiring younger inquiring Elixir engineers also, but the question is about why isn’t it mainstream not how to find a diamond in the rough.
If you are running a company today the fact of the matter is Elixir a a executional Risk and the Reward the risk gives clearly isn’t worth it for most startups or else it would have higher adoption.
For 99% of things, language performance doesn't really matter (it's usually cheaper to just scale up). So you might as well focus on developer experience and hire-ability.
For the 1% where it does matter, drop down to something like Rust, and use the developer-friendly language above as glue.
You see it a lot in Python, where the performance of the runtime itself is kinda crap, but it doesn't matter because it's very developer-friendly. It became the #1 language for high performance data science, thanks to libraries that use C and stuff under the hood.
It does offer a boost, but in the form of system reliability in a concurrent environment. This kind of advantage is seldom properly evaluated until AFTER you have a disaster ... by which time you are typically committed to different stack.
this : http://www.paulgraham.com/avg.html comes to mind.
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.
1) There's plenty of Elixir engineers, and most of them specialize in web development or a domain thats web dev adjacent. Python is used for everything, with loose conventions on how to program in each domain.
2) Rust maybe faster than Elixir... but what about things like concurrency across multiple nodes and fault tolerance. Fearless concurrency, etc. also, it's really not that hard to create NIFs in Rust. It's really hard to do the above in Rust.
2.a) for most kinds of developement where both rust, python, and elixir could be used to solve a problem (web dev/data science)..... speed is probably not something you are worrying about.
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.
I've seen 8 years of Elixir, and still get asked to return the world when FE wants data. No they won't ask for bits.. They want the user info and the company info for the user, and the client list for the user, and the company details from the client list for the user.. and they want it all in one response. BEAM becomes a useful tool you'll never reach for.
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.
I think it's common to see a mismatch between enthusiasm and market success in programming languages because programmer tastes vary widely, and are also not evenly distributed. Sometimes certain groups who are most enthusiastic about certain technical features of a language (and I would say those who are most enthusiastic about programming languages in general) find it hard to accept that their preferences are only shared by a minority.
Adding to the confusion is the fact that there is a numerically large (but proportionately very small) group of programming language enthusiasts that give some languages a big early boost, raising hopes, but then that pool is exhausted. So getting to 1% and generating hype is not as hard as showing stable and growth and getting a large community that sticks with you for over a decade.
The former tend to peak early, powered by marketing departments, and then slowly tail off; the latter tend to do the opposite, because word-of-mouth is slow; community-powered peaks are often determined more by the appearance of a successful product based on it (Rails, Elixir, etc) than time from creation.
JavaScript, Python, and Ruby are all counter-examples. Erlang and Haskell might as well.
I don't think time plays such an important factor. A language may exist for 20 years and then a large corporation or an all encompassing framework draws attention to it, leading to unforeseen growth.
> In other words, if you're not at 5% market share by age 10, chances are low you'll ever reach 10%.
This won't happen for 99% of programming languages and it shouldn't be a goal or even a comparison point. For example, on GitHub language stats [1], only three languages have more than 10% activity, only 7 within 5% activity. Pick other rankings, market share related or not, and you will find similar numbers. Tiobe lists SQL, Go, and PHP all below 2% and I don't think anyone could argue they failed at market success.
> So getting to 1% and generating hype is not as hard as showing stable and growth and getting a large community that sticks with you for over a decade.
Given all of the above, I strongly disagree. Getting to 1% is incredibly hard.
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.
* The entire model of state with Genservers
* Pattern matching made my code unreadable
* Libraries that I needed had Erlang documentation
I created some pretty gnarly code when pattern matching authorization cookies for some Plug middleware I made. Plus I had to dive into some Cowboy stuff, which had really awful documentation at the time.
"Just use Phoenix!" is what most people will say. But I simply don't want to use a big framework for a straightforward server.
Again, I realize that Elixir is probably really good at what I need it for. For instance, my latest project is a collection of Go binaries that all run at once and process data back and forth. This can likely modeled as processes under a supervision tree in Elixir as multiple Genservers... but Jesus. That's so much harder for me to think about.
What if I want to scale a specific worker up/down? With a Golang binary I can just... launch more containers with the binary. Elixir on the other hand has its own orchestrator of sorts with BEAM. So what do I do here? I guess I need to launch more Elixir servers with my code and then configure something so that it launches more processes of a certain kind within my fleet, but I have 0 effing clue how.
Edit: going through the docs, I just remembered another thing: most of the things I design are dependent on a store of some kind, whether its Redis or Postgres, or any other store. That can be confusing when the Elixir docs have a focus on its own state solutions, like GenServer or ETS.
I do everything with Go and Node+TS. All API services, real time / notifications, and crunchy stuff happens with Go. Node+TS handles anything else for either 3rd party things (usually the node sdk is far superior in terms of documentation and support) or one off scripts.
I've tried phoenix. End of the day I don't want to work with something which is built on something else which I don't know/understand to an even bigger degree. And fwiw, I don't see the point of deep diving into erlang/beam when Go basically does everything plus more, within its boundaries. Reminds me of JVM, you can code all day in Scala (like any junior engineer) but at some point either when shit hits the fan or incompatibility strikes, you need to learn Java and JVM internals.
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).
Rails/python are immediately productive and you need minimal knowledge to start reaping benefits.
Of course once you start doing complex things you need to obtain that knowledge but it can be a gradual process
4. A critical mass of community packages and open source ecosystem so you don't re-invent the wheel for non core things (eg. Javascript, Python, Rails)
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.
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.
I'm currently working on a backoffice software. You can do that with literally any language/framework. But as you mentioned, adding near-instant sync for different users would simply be a breeze compared to any backend with a React-ish frontend from what I saw so far. And I can totally see affordances for such a type of software going into this direction.
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.
As a consultant, startup founder, employee?
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.
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
If you're all alone, there are still tons of guides, books, blog posts, et al. Documentation is a first class citizen in Elixir, and theresIf you're on a good team, they'll get you resources. If you're on a bad team? {shrug}
I don't agree at all... tRPC/Prisma have been a joy to work with. We still use a traditional SPA app.
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.
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.
Python is one of the oldest languages that is still in active use, predating Java.
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.
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.
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.
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.
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.
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?"
The defacto pattern matching approach for everything gives every function an interface and you still get strong typing for all of your core types too (numbers, strings, bytes, etc).
You just don't have static typing, but the typing that's there is significantly stronger than dynamic languages and IMO it has the perfect blend of wins from static typing without the flexibility impairments that come with it.
Although most elixir code I've worked with was written by guys coming from ruby/java, and they just couldn't resist abusing macros for emulating inheritance, or overusing macros per se, once you switch your mind and clean that shit up, elixir is more maintainable than golang, for example (working for go company now). It has more tools to manage complexity and boilerplate, while nearly all golang code is complex/boilerplate itself.
But it's just like any other framework in that, if you want to write bad code, it won't stop you.
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.
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.
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.
Maybe one of them will be the "next big thing."
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.
What do you mean by this?
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.
using an all-in-one framework almost always means that i have to start from scatch for a new project because the reusability is much more limited.
fly.io? https://news.ycombinator.com/item?id=28621478
> 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.
LiveView / the "PETAL stack" are my first choice for web applications due to productivity & developer experience. Great summary here: https://thinkingelixir.com/petal-stack-in-elixir/
You can also see the resources on this page listed by year: https://github.com/phoenixframework/phoenix/blob/main/guides... - the recent launched ones are most likely up to date.
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.
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.
Erlang's goal was never to be your company's message bus. Or your k8s. Even hot restarts have always been advertised as an extremely specialized feature, justified only for very specific use cases. So you are right, if someone wants to use Erlang for these specific purposes, then I would ask them to triple check their decision.
> 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
Agree/disagree. I agree that fault-tolerance must not be an application developer concern. However, it is a huge plus to know that my web server, connection pool, ML serving, and other essential libraries are backed by supervisors instead of crashing and getting into a unknown state. And those are errors a type system won't catch anyway: "oops, your database sent a tcp packet you were not expecting, good luck!"
> 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.
Agreed and that's precisely the selling point. If you have to build an application that needs to concurrently talk to several APIs, or perform background processing, or do real-time messaging, or distribute machine learning workflows, then you can build such application using Erlang/Elixir without bringing Kafka, Redis, or much else into the equation. Replicating this elsewhere will often require stitching three or more technologies together, which become additional techs to learn, master, and maintain on every step of development, test, and production.
In any case, I still find it "incorrect" (sorry, I can't think of a better word) to judge Erlang and Elixir by the unmet potential of its _exceptional_ features. Even if you strip distribution, hot code swapping, supervisors, they are both excellent dynamic languages with concurrency capabilities that are not seen on other mainstream dynamic languages (although I am obviously biased). If you are chasing system-level performance or static-typing though, then they are obviously not a good fit.
Ultimately, I find the question of adoption is way less technical and rational than most people expect to. That's something we often hear about technology in general, and I don't think programming languages, frameworks, etc, are much of an exception. :)
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.
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.
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.
In fact, you can build a release that's just a zip file which also contains the full elixir/erlang runtimes, that can be deployed on a barebones server (assuming the same libc, etc). It's not "single-executable" nice like Go/Rust/.NET but it's much simpler than it used to be.
The one use case we've seen for clustering things is having our cache stay in sync. But apart from that, we really haven't seen a need to cluster our nodes.
But if we wanted to, it's beautifully and trivially easy to do things in a cluster in Elixir/Erlang.
Immutable state is definitely one of the steeper learning curves to get over.
I'd be curious to hear more about how elixir makes running a cluster easier from a devops point of view. At the end of the day you probably still want to use something like kubernetes right?
