Erlang was picked for a particular reason. WhatsApp uses a prebuilt open-source chat solution, an XMPP server written in Erlang, ejabberd. This thing was first released in 2003 (old). Already a smart move to get started.
I’m pretty sure they hired Erlang developers to dig into ejabberd internals and optimize certain things. They didn’t just decide to become an Erlang shop out of the blue.
It wasn’t Erlang that was the initial right choice, it was using xmpp and ejabberd that was the root reason. Erlang just happened to be a consequence of that.
I will contest your attribution of ‘smart’ with Erlang. These types of correlations are generally bias fitting. It justifies ‘smart’ being correlated with any and all niche languages, eg ‘so and so likes Haskell, so they must be smart’. No good.
It’s better to attribute ‘smart’ with the pragmatic decision they made to simply use a pre-existing chat server solution that already has the capability to scale. Harder to assess this as smart since there’s no ‘signaling’ here, you have to objectively assess if it was the right tech (which it seems like it was). Way less vanity in this assessment as opposed to what I already pointed out, how your Haskell or Rust devs must be particularly smarter, as opposed to say PHP or JavaScript devs who are considered dumber. I don’t buy it, I need to see more than just your affiliations.
So, I reject your initial post contending ‘The technology stack isn't even that relevant.’ It was precisely the tech decisions that mattered, and the right people to make such decisions. Chicken and egg scenario, I’ll concede that.
In any case, one does not simply pick a old chat server written in Erlang out of the blue - this decision was critical. How many over-funded tech teams would try to do this from scratch in Go? Plenty, and that whole team would easily be full of ‘smart’ people.
> I’m pretty sure they hired Erlang developers to dig into ejabberd internals and optimize certain things. They didn’t just decide to become an Erlang shop out of the blue.
Eh, I was there since October 2011, and we didn't hire any people who knew Erlang until much later. All of the early server engineers (including me) learned it on the job. By the time I left in 2019, I think we hired two people to the server team with previous Erlang experience; it's hard to find people with it, and while it might have been nice, it's not important.
It's possible we had some consulting possibly before I was hired, but I don't remember seeing any evidence of that; OTOH, I do remember setting up and working with a FreeBSD consultant and Moxie when he was consulting on end to end. From my understanding, when things started bottlenecking, Rick Reed was hired to fix bottlenecks; which he had been doing at Yahoo! for many years and had worked with Jan and Brian there.
FWIW; WhatsApp the service started as just a text status, built on PHP and MySQL, but people were using it to chat, so the founders went looking for a chat server to use rather than building one from scratch. I don't know the decision process, but ejabberd was then powering Facebook chat at the time. (Of course, Facebook abandoned Erlang, they said because they couldn't find people with Erlang experience to hire)
Anyway, by the time I got there, I was told that the chat server had been mostly refactored over time and while a lot of names remained the same, and some of the basic architecture was the same, it wasn't ejabberd anymore. Mostly I worked on things that weren't chatd, and I don't think I've seen ejabberd code, so I can't verify, but it seems likely, as we customized the protocol, auth, offline messaging, contacts, session handling, etc.
Erlang is a tremendously right fit for a chat server, and hot code loading is almost necessary when you have hundreds of thousands or millions of connections per chat machine and want to push small changes. Of course, changes to BEAM itself, or the OS kernel take restarts, so you still need to do those from time to time.
I’m pretty sure they hired Erlang developers to dig into ejabberd internals and optimize certain things. They didn’t just decide to become an Erlang shop out of the blue.
It wasn’t Erlang that was the initial right choice, it was using xmpp and ejabberd that was the root reason. Erlang just happened to be a consequence of that.
https://www.ejabberd.im/
I will contest your attribution of ‘smart’ with Erlang. These types of correlations are generally bias fitting. It justifies ‘smart’ being correlated with any and all niche languages, eg ‘so and so likes Haskell, so they must be smart’. No good.
It’s better to attribute ‘smart’ with the pragmatic decision they made to simply use a pre-existing chat server solution that already has the capability to scale. Harder to assess this as smart since there’s no ‘signaling’ here, you have to objectively assess if it was the right tech (which it seems like it was). Way less vanity in this assessment as opposed to what I already pointed out, how your Haskell or Rust devs must be particularly smarter, as opposed to say PHP or JavaScript devs who are considered dumber. I don’t buy it, I need to see more than just your affiliations.
So, I reject your initial post contending ‘The technology stack isn't even that relevant.’ It was precisely the tech decisions that mattered, and the right people to make such decisions. Chicken and egg scenario, I’ll concede that.
In any case, one does not simply pick a old chat server written in Erlang out of the blue - this decision was critical. How many over-funded tech teams would try to do this from scratch in Go? Plenty, and that whole team would easily be full of ‘smart’ people.