He is actually wrong here! Erlang IS about lighhweight processes, message passing and basic error handling. it was these properties of the semnatics of the language that were developed from the very beginning.

The language was designed around our I ideas of what the problem really was and the best way of solving it. The massive and extremely lightweight concurrency were a critical part of attacking the problem which was/is extremely concurrent. There are an enormous number of things going on in a switch which have to be handled concurrently, sometime over 10k calls plus running the switch. So the concurrency was fundamental. The error handling primitives were of course also a critical part of the solution as fault tolerance was a critical part of the problem.

A lot of effort went in to working out what the concurrency and error handling should look like to be right for how to attack the issues and solve the problems. Fortunately we worked with a user group looking at designing a new architecture who tested using our ideas and came with extremely important feedback on the ideas, what was good or bad or just not necessary. They then became the first group to build a product using Erlang.

OTP came later and is “just” a formalised, generic wrapper around these ideas. We had client-servers, state machines and the equivalent of supervisors in products before OTP was developed. Behaviours came with OTP. And in the beginning there were many different versions of OTP alive at the same time.

Behaviours could not have been developed as they are without lightweight processes and communication. OTP is of course fundamnetal to the distribution and use of the language as it does encapsulate most of of our original ideas in how Erlang should/could be used to build systems.

I will have to get into the discussion on Hacker News.

Now I am in for real as I have entered a comment.

While go doesn’t have the fault tolerance built in the runtime, I do think that using an abstraction like genservers is a must in that language. While I don’t have that much go experience, I find that using raw goroutines is like using process primitives in elixir, prone to error (not to mention deadlocks) and a lot of scaffolding that is repeating itself.

As for the part of nodes implementation, this does seem to be very peculiar.