tags : Programming Languages, Actor Model, Distributed Systems
FAQ
State of erlang
My thoughts on these topics are a bit convoluted, so please forgive any disjointed ramblings.
Go and K8s are not really serious contenders for what OTP/BEAM do. They can, in fact, work complimentary to each other. So there’s nothing really in conflict or one “taking over” the other.
That said, if you tried to use Kubernetes as an supervision framework a la OTP, you’d have a… bad time. Kubernetes doesn’t support hierarchical or structural supervision, it has extremely dumb restart strategies, etc. There are much more fine-grained controls with OTP, where you can control exactly how your application degrades as external services fail. Kubernetes used in this way would be basically a giant, single-layer supervision tree with a single root guardian — i.e. absolutely terrifying and crude to an Erlang developer.
You can use Kubernetes to orchestrate disparate Erlang services, and many people do. But that actually doesn’t take anything away from Erlang, and languages like Go don’t gain anything either — because, again, Kubernetes would make a rather anemic OTP.
We often joke:
Any sufficiently complicated cloud deployment contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang/OTP.
I can say this: where I work, we deploy to severs. We do clustering, we upgrade by hot-swapping, the whole nine yards. Internally, we did a study, and the product would not even be profitable if it were moved as-is to a cloud provider. I cannot even imagine how much worse it would be if it were re-written and the workload distributed among dozens of containers.
For Elixir — it is a nice language, which I kind of prefer in many ways. However, many of the differences in syntax are superficial, and the community is centered around Phoenix and user-facing web development, which is usually not what we build with Erlang. Where I work, we are 80% Erlang and the Elixir is what we call, “Erlang style Elixir” because we find Phoenix to be too much. OTP is enough. There’s really no strong incentive or migration to move to Elixir, we still write new Erlang, it’s kind of just what whatever developer feels prefers.
By far the most interesting Erlang-alternative on the BEAM is Lisp Flavored Erlang.
Gleam looks nice, however, my understanding is that it has pretty minimal compatibility with OTP and drops things from OTP that aren’t typesafe. That kind of defeats the purposes, at least where I work, because Erlang is almost a DSL for writing OTP. I know the trend is towards languages with outrageously sophisticated type systems, but I think if you focus on small, composable modules, dialyzer is enough. Types have never been a problem for us, I feel like this is a bit of a solution looking for a problem.
That said, if you’re into types, my understanding is that Purescript compiles to BEAM and is compatible with all of OTP, if I am not mistaken.
So, to answer your questions:
- Erlang good
- OTP good
- Erlang is growing where I work, albeit modestly
- Modern cloud infra is complimentary to OTP, it doesn’t replace it
- Even so, I assume many shops are “stuck” with Erlang like us, in that our product would not even be profitable if it were moved to fancy K8s/Fargate deployments
- Elixir, Gleam etc are all nice, and I hope they bring more people to BEAM, but they aren’t compelling enough for us to re-write anything
- Dealing with K8s/Fargate/modern cloud is absolutely painful after experiencing OTP
OTP (Open Telecom Platform)
- Erlang is almost a DSL for writing OTP.
- BEAM is the vm