Interesting. I've noticed the similarity between Kubernetes and Erlang as well, but what it brought to mind was Virding's Rule: "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."
And actually Kubernetes is pretty cool, but between the complexity of configuring it, and the fact that it only operates at the level of heavy-weight OS processes, makes me wonder whether it really is much of an advantage.
To be fair, while I have used distributed Erlang, I haven't used at the scale that my current employer uses K8s, so I probably don't have an accurate comparison.
(An aside: There are some people from the Erlang community who dismiss the notion of Go as a competitor of Erlang, on account of the many things Go lacks compared to Erlang. Your comment made me realize that the real comparison is not between Erlang and Go, but between Erlang and Go + Docker/K8s)
Right. Kubernetes does have its own operational complexities. The way you're now thinking of Erlang vs language X is also how I think about it.
My experience has been that Erlang is a very all or nothing investment. You need employees to read the literature, understand all the components, and then dive in.
With containers, you need to understand the very basics of building images and deploying processes, but you don't necessarily have to scare people with Kubernetes until you get to sufficiently large enough scale. Moving from compose to pods is a headache, but it's not as difficult as migrating from say mnesia to an sql database.
That's a fair point. I'm wondering, are there situations where the all-or-nothing investment in Erlang pays off?
Something I've noticed is that companies that adopt Erlang the language do tend to go for the whole hog. In that case they tend to build their whole infrastructure using it.
On the other hand, companies that are coming to the Erlang VM via Elixir often have existing infrastructure and applications written in another language (PHP, Ruby, etc.) and they're looking to get better scalability within a given application, while still leveraging their existing infrastructure.
The Elixir folks are more x-rubyists than Erlangers. They are trying to change Erlang so it will be less whole hog as you say. At the same time they've brought the rails mentality of heavy framework/macro use which has its own problems.
I think the investment can pay off if you're falling into an area that Erlang really excels at, or if you're going to fork an existing Erlang project that already does something you want. Erlang is really good for anything that is telecommunications-y like chat systems, message queues, and custom protocols. It has A+ syntax for parsing binary protocols, which can speed up development.
Erlang is also a good choice if you really need something that needs to be consistent rather than efficient. While requests aren't going to be handled at lightning speed, as you add users latency should stay in a fairly predictable spot. Erlang's message queues tend work best on high memory bare metal nodes, and as long as the queues are taken care of, the system will scale.
But I wouldn't generally recommend it. It's hard to predict if you'll need to scale, and if you do, you'll have to swim in a much smaller community where most of the knowledge is done face to face because everyone knows each other from Erlang Factory. The industry has finally gotten around to solving certain horizontal scaling issues, and as we've already discussed containers can make crashing acceptable at the host process level).
I do recommend reading Joe Armstrongs Erlang book. Erlang is a great way to expand your horizons, and I hear that in Europe they use Erlang to teach classes on concurrency.
And actually Kubernetes is pretty cool, but between the complexity of configuring it, and the fact that it only operates at the level of heavy-weight OS processes, makes me wonder whether it really is much of an advantage.
To be fair, while I have used distributed Erlang, I haven't used at the scale that my current employer uses K8s, so I probably don't have an accurate comparison.
(An aside: There are some people from the Erlang community who dismiss the notion of Go as a competitor of Erlang, on account of the many things Go lacks compared to Erlang. Your comment made me realize that the real comparison is not between Erlang and Go, but between Erlang and Go + Docker/K8s)