|
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 integration itself is a feature that very few other platforms can compare with! While I can find every feature now in other languages and environments, I will be putting together a stack of my own somehow, which can be beneficial, but is also definitely a cost of its own too. But other than that, BEAM doesn't bring much special to the table anymore. It is very easy to put together a stack in many other languages that exceed it in one or more dimensions, and those are often the dimensions you care about a lot (performance, static type safety, language-agnostic message busses for heterogenous deployments, there are languages/runtimes now better than even BEAM at managing tens/hundreds of thousands of simultaneous connections now... any of these can easily be a determinative factor). But its bucket has a thousand little cuts in it for the water to leak out of. No one big gash by any means, but a lot of little holes. [1]: https://news.ycombinator.com/item?id=37261154 |
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. :)