> Section 4.8. Fellows. To be eligible for membership as a Fellow, a member must be nominated by a Fellow of the corporation [...] Upon election, a Fellow shall remain a Fellow for the remainder of such person’s natural life, subject to any limiting provisions of this document. Fellowship does not continue during any extension of life by non-natural means, such as zombification or vampirism.
Would non-natural include medical interventions, or is it clearly meant to mean "supernatural?" What if someone says they were saved by a faith healer? It is only a matter of time before these claims are tested in the courts.
I mean, have you used Facebook chat, Pinterest, Discord, RabbitMQ, CouchDB, SimpleDB, Riak, T-Mobile SMS, or GRPS/3G phone service? If so, you're using Erlang probably quite a lot!
I don't think that matches what most people mean by using a language, if you use those applications you are using applications that use the language but you do not use the language yourself. Although in CouchDB you can write plugins in Erlang so maybe.
Facebook chat did use erlang (Ejabberd to be precise), but they migrated to something other. WhatsApp uses erlang and is even a member (logo in partners section). So, Facebook uses erlang, but not directly as Facebook, but they changed tech stack away from erlang.
For some context, readers of the parent comment should know that the commenter routinely makes similarly negative comments on every other erlang/elixir article to hit the front page.
Edit: in response to sibling comments, I believe they like rust.
Indeed, I’ve also noticed this pattern of negative comments whenever the Erlang/Elixir topic comes up. Thanks for pointing it out.
Erlang/Elixir are fine languages, running on top of an advanced and optimized VM, designed for fault tolerance and superb concurrency. And if need be, one can always integrate it with other languages, including commenter's favorite language, Rust.
Because I actually worked professionally with Erlang and don’t think it’s a magic silver bullet my opinion is invalid? People should have a chance to hear alternative perspective and have a technical debate if they so chose.
I said in my post that I learned a lot from Erlang and it broadened my perspective, which is hardly negative. But there were also a lot of issues, and for all the good things Erlang did it also had a number of pain points in scaling and working with mnesia, dialyzer, even basic OTP building blocks. Erlang was also extremely difficult for my company to hire for, and pretty much everyone who came in had to learn Erlang from scratch, which was costly in terms of project time and meant we had essentially junior developers writing unfamiliar code.
Erlang is also a constant fight when deploying with a container orchestrator. They are two totally separate approaches to scaling and making Erlang act as ephemeral and have any value in a the ephemeral world is a huge pain that people should be aware of.
We use Kubernetes to give us the same level of reliability and scalability as Erlang, which was Erlangs primary value add. You can then pick a language, or any number of languages in a more service oriented environment.
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.
We use a combination of tools/languages to reap the same benefits of Erlang. Erlang is designed with some very static assumptions in mind. Nodes aren't really supposed to go down, and upgrades happen in place. This is counter to how modern deployments seem to be heading with rolling restarts and super ephemeral services. So using Erlang was really cutting against the grain of where the industry was heading, and Kubernetes is giving us the same end result of high availability and horizontal scaling.
> Section 4.8. Fellows. To be eligible for membership as a Fellow, a member must be nominated by a Fellow of the corporation [...] Upon election, a Fellow shall remain a Fellow for the remainder of such person’s natural life, subject to any limiting provisions of this document. Fellowship does not continue during any extension of life by non-natural means, such as zombification or vampirism.