4 ms·

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 registerin

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.

jimmy1 8y ago
"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/039261.html 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.