Are you talking about Go, the language this is written in?

Go's concurrency features are formally specified, are not ad-hoc (they are a major feature of the language, and the product of multiple language design iterations) and are certainly not bug-ridden.

Or are you talking about using Kubernetes to manage workloads on machines?

How does Erlang solve running my python webapp or my SQL database on my ec2 nodes, or in the case of this project, on an IoT device.

I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us of knowing about Relational Databases. If you approach the tooling infependently though, as a true knowledge expert does, you will see the progress made by other giants in these fields who are not afraid of specialised tools.

When I came across Erlang last year at a new company, I thought it was interesting how many problems Erlang solved that were also in Kubernetes. Self registering named services, processes that crash and restart automatically, health checks, etc.

Unfortunately to use all those features the services needed to be written in Erlang of course, which isn't bad in itself, but unfortunately not the reality in todays multi-lingual atmosphere. Speaks to how highly Erlang was designed and written. It took a lot of real life operational concerns into account in it's design, a concept few other languages even attempt to address.

"Who cares that these problems are solved in Erlang/BEAM if hardly anyone is writing end user software in Erlang/BEAM/Elixir", basically.

My number one reason for not using Erlang is lack of static typing. Dynamic type systems are great for small teams, not so great for "enterprise-wide" development. (I know this horse has been beaten to death here, trust me, I have heard the arguments for/against millions of times, I remain unconvinced).

Also the answer to this question is interesting to me as well http://erlang.org/pipermail/erlang-questions/2008-October/03... -- (granted this is from Oct 2008) apparently if you were to attempt to add static type checking in Erlang, it would have to fundamentally change some of these benefits erlang brings such as message passing and handling process death. Haven't been part of the erlang scene for a while, but would be interested to hear a rebuttal to that.

I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang.

We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time.

In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of the autoscaler nodes are dynamically provisioned when needed, and then removed when the test environment is destroyed. That's pretty nice functionality you get basically out of the box. On EKS anyway. There are some occasional rough edges, but I think the decision to use k8s for this makes sense...

At some point we'll migrate prod too.

Kubernetes has a lineage as well... Based on the Borg project at Google.

I guess I'm not seeing why these things are being compared. Aren't they solving different problems?

I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system." Does that ring any bells?

[1] https://en.wikipedia.org/wiki/Erlang_(programming_language)

So you're suggesting we use BEAM instead of Kubernetes?

So just rewrite all our code in Erlang, including off the shelf products we didn't write?

Then use some other technology to deploy the software, configure the machine, come up with a way to do service discovery, attach block devices to nodes, and automatically provision new machines based on resource usage?

It doesn't make sense yet it's seemingly repeated on every thread about Kubernetes.

The Erlang community should celebrate technologies like Kubernetes, Mesos, or any other number of resource scheduling systems because they're finally the industry taking seriously the problems addressed by Erlang.

The biggest difference is BEAM is Erlang which imo is what's done wrong, Kubernetes is language neutral, it's a platform not a language runtime.

Similar to what Envoy is when you do service mesh, you don't need to integrate libraries into your code to get service mesh features using Envoy as side car proxy.

I have that conversation with Erlang users on every k8s topics, they seem to miss the point that decoupling features outside of the language / runtime is the way to go.

Not sure what point you’re making specifically. Could you elaborate?

What are "these problems"?

Erlang is a terrific platform, but it isn't very accessible to the wider population.

Timely, here's antirez on this topic when Redis was announced on HN ten years ago [0]:

> There are a lot of projects similar to Redis in Erlang actually: http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib...

> Apart from speed what I like of C for this kind of projects is the self-contain-ness and the fact that most developers that may help in the development are probably able to read/write C but not Erlang.

[0] https://news.ycombinator.com/item?id=494903

IMO any program with a sufficiently high number of entities in a low level language contains an ad hoc informally-specified bug-ridden slow implementation of a garbage collector

Not exactly, a garbage collector is by definition a collector (there is sweeps rather than per-reference and more importantly has runtime cost). I think, manual memory management is a lot more similar to a poorman's ARC implementation.

A poorman's ARC implementation might not collect cycles, but it does not do double free() or use-after-free().