Hacker News Reader

Comment by nickbauman | Hacker News Reader

They chose Erlang. A language built for communication and managing wire protocols at scale. Which describes WhatsApp itself. That was probably the biggest impact single decision for WhatsApp technically.

View on HN

I am not sure if WhatsApp engs chose ejabberd because it was written in Erlang or because ejabberd was the defacto implementation of XMPP. They stumbled upon and fixed bugs in BEAM/OTP at their scale [0][1][2]. They also ran FreeBSD (for its superior networking?) on bare-metal hosts running customised system-images [3] and employed networking experts at some point.

[0] https://www.youtube-nocookie.com/embed/c12cYAUTXXs

[1] https://www.youtube-nocookie.com/embed/wDk6l3tPBuw

[2] https://www.youtube-nocookie.com/embed/93MA0VUWP9w

[3] https://www.youtube-nocookie.com/embed/TneLO5TdW_M

I could be wrong but I think freebsd allowed multiplexing connections per port before Linux? Please correct me I am mistaken about this.

They ran FreeBSD because Jan came from Yahoo, and that's what Yahoo ran.

'customized systems (kernel)..FreeBSD..bare metal': Which is what most of us still do if we care about performance for a single application. Running openmp fortran code for both host/accelerator on oversubscribed vmware or vanilla kvm/qemu for a good laugh and a lot of pain. Simple systems approaches are best even when what you are doing is complicated.

Erlang is like Bugman from the Nightmare Before Christmas. It is literally made out of microservices at every level.

Microservices are a design philosophy that people confuse as a deployment strategy.

Not necessarily, you can design erlang systems with more coupling than you'd expect in traditional microservices. Microservices mean that your codebase is segmented along business concern lines.

I would rather argue that microservices are best implemented when each service owns a bounded context in the lingo of domain-driven design. Business concerns might align with that, or they may not, depending on how technically complex (vs product complexity) the product is.

Yes, that is a better definition, but nonetheless you can design erlang systems with a single domain, or design erlang systems as a monolith, even if it has a billion actors running around underneath.

> Microservices are a design philosophy that people confuse as a deployment strategy.

I'm going to print this and show everyone, great words, thank you.

Kinda, yeah, except Erlang is microservices made easier. I've loved how the language makes building distributed systems so comparatively easy since I ran across it back in 2005.

That was probably the biggest impact single decision for WhatsApp technically.

As a rule of thumb based on my own experiences and the opinions of more experienced engineers I've had the good fortune to work with, language choice is far less important than the quality of the team using it.

While I have no doubt that trying to build WhatsApp in a language that would be the wrong tool for the job (say... PHP) would have been fatal, I have many more doubts that choosing Erlang was the key enabling decision.

Language choice I can perhaps agree with, but from what I've read, the biggest factor with Erlang is much more its runtime environment. BEAM + OTP is a very impressive piece of kit.

Converse: Can you imagine WhatsApp parallel universe serving with Node?

Yes :)

Success is more to do with user experience..

If you hit gold and scale you can almost always optimize the implementation later.

Iirc Slack's backend is PHP.

They've moved over everything to Hacklang, which is a derivative of PHP.

I don't know. Erlang is a "funny" language that can somewhat easily do certain things that would be much more time consuming to accomplish in a more mainstream programming language. The difference between building whatsapp in Erlang vs any other programming language is probably larger than building it in php vs any other mainstream language.

It's amazing how much effort it takes to do something with the wrong tools.

Sunk Cost Fallacy tends to fight any broad-stroke improvements. Until a competitor starts eating your lunch.

Reply on news.ycombinator.com