What I like most about some experienced engineers who have been at companies from the beginning is that they realize the needs of a small-team, cash-constrained, rapidly growing company are different from that of a dozens-of-teams, complex, but also rapidly scaling enterprise. The devil is in understanding when and how to transition your tooling, architecture, and — dare I say it — attitudes, from the one to the other.<p>I am curious to hear more from these engineers; how decisions were made about transitioning/scaling; and what decisions were made.
One of my favorite talks is by Rick Reed about scaling Erlang at WhatsApp. What an absolute savage. He flies through an articulate and in-depth curriculum on system performance and bottleneck mitigation.<p>The talk is called "That's 'Billion' with a 'B'" and makes for a great lunchtime watch: <a href="https://www.youtube.com/watch?v=c12cYAUTXXs" rel="nofollow">https://www.youtube.com/watch?v=c12cYAUTXXs</a>
Erlang is the Actors-model version of Greenspun's tenth rule of programming:<p>"Any sufficiently complicated server backend contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang."<p>Is it really the end-all-be-all model of server architecture? What are microservices, if not Actors Clunkified? "Serverless" functions, if not the simplest actors in disguise? Docker, actors except over IP addresses and clunky APIs?<p>The real takeaway: Valuable stuff is stateful. You know you're doing valuable work for a real human end-user if you are dealing with tricky state problems. Extracting money out of that is a bunch of developer-productivity-limited business concerns. It seems actors are a good model to solve that.
I absolutely love the BEAM and Elixir, but one of my common complaints and source of errors is the lack of compile-time type sanity checking, so I'm excited to see movement in this direction. Dialyzer is sorta okay, but the speed, cryptic errors, and syntax have kept me from fully embracing it.
I find it funny they say Whatsapp "chose" Erlang. They "chose" Erlang because ejabberd was written on it, and they chose ejabberd because of a Jabber mailing list suggestion. That's about it...
> "We are working on a prototype, open-sourcing in November"<p>I'm curious to see how Elixir integration with such static type system would work.
Last I heard (years ago), I though that WhatsApp's backend was being rewritten in some other language, because Facebook didn't think maintaining an Erlang codebase was tenable. Did that change?
Working in a small Company always let me astonished learning things about unicorn apps. But really an application like Whatsapp need 1000+ developers!? I can think about teams about android, ios and web app. X2 if you think about teams for business oriented services. But 1000+ developers for what?
> shift to modern languages with integrated tooling, e.g. Erlang competition:<p>><p>> C++, Java => Go, Rust, Kotlin<p>My first C++ IDE was Turbo C++ 1.0 for MS-DOS in 1993, and Borland, Zortech, Symatec, Microsoft, IBM, and plenty of others had well known C++ IDEs.<p>Many of the ideas of modern C++ IDEs is basically rediscovering the work done by Lucid and IBM with their Smalltalk like capabilities for C++ tooling in the late 80's/early 90's.<p>Java is well known for being one of the languages with best IDE support out of box. It didn't start like that in 1996, but the last 25 years have been good to it.<p>Go and Rust are yet to have similar offerings and Kotlin, well it is a JVM language and profits from the Java eco-system and Google's push to replace it on Android due to non-technical reasons.<p>Maybe better examples should have been provided.
I think the concepts are very interesting of Erlang but I still don't understand it fully. And also about the multi-node os only an internal network scenario is not like a cloud mesh thing. You would need docker.