> 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.
Before people downmod this, I'm an Elixir developer - just curious who wrote it. It doesn't _seem_ official.
Edit: I see Jose there, it's legit! https://twitter.com/sheharyarn/status/1101306957531570176
I read Joe Armstrong's Erlang book and really liked the language. I hope it gains more traction so there is more opportunity to use it.
WhatsApp is now owned by Facebook.
Are you saying they changed the tech stack for WhatsApp?
Edit: in response to sibling comments, I believe they like rust.
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.
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.
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)
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.
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.
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.