Some folks here might enjoy reading a recent article called “Erlang’s not about lightweight processes and message passing…”. It’s a pretty deep dive into the idea of behaviours, with side expeditions into various related topics.
If nothing else, the article prompted me to start reading Joe Armstrong’s (very engaging) dissertation. I’ve also skimmed the freewheeling discussion of the article on Hacker News.
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.
I will have to get into the discussion on Hacker News.
You’re already there, at least by reference. :-}
Now I am in for real as I have entered a comment. 
I’m now very curious if you saw this more recent thread about Ergo and your thoughts if you have the cycles to share.
Before clicking the link I thought this was going to be another “I made an event loop and called it GenServer”… but hrm. Wow. Interesting.
Always my question with stuff is… if these concepts aren’t enforced by the VM, kinda what’s the point?
Ruby’s Celluloid was an exercise in futility, imo. Granted Go is a lower level type language, so it’s kinda understood that you can always circumvent the frameworks.
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.
Ahh, I want to retract my previous statement now… 
Not about Celluloid though… 
(There are too much information on Hacker News, I would like to quote some worthy-mentioned replies here)
I like what hosh (a HackerNews user) said:
I think it (the article) is misleading to frame this as “behavior”. I think what we really have are battle-tested concurrency patterns, which then uses the language feature called “behavior” to implement. This collection of battle-tested concurrency patterns that has been in use for a long time, in a variety of settings, is called OTP. It’s why you’ll hear long-time Erlang folks talk about how, it’s really about OTP.
You can implement those same patterns, if you also have lightweight processes, messages, and message queues. There’s a Rust library that aims to do exactly that. The new WASM runtime (Firefly, formerly known as Lumen) aims to bring those patterns into the WASM ecosystem, potentially using this kind of concurrency pattern client-side.
And what rvirding (Robert on Hacker News, yes!) said, too:
OTP came much later than the design of the language.
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 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. It didn’t use OTP as it didn’t exist then.
OTP came later and is “just” a formalised, generic wrapper around these ideas. We had client-servers, state machines and the equivalent to 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.
That makes sense. I don’t know a lot about Go. My only “real” experience with it is Hugo, which doesn’t really count. That’s interesting, though, and makes sense since I’ve talked to Go programmers who complain just that: they call a goroutine and then hope for the best. But thanks, this was the type of insight I was looking for!
I worked a few months at a small company in golang and I convinced myself that 80% of the development time was just reinventing the wheel (I had to make a custom http client for an api from scratch, since the ecosystem didn’t have any decent libraries capable of abstraction), it took me about 1 week of writing code to complete that client, when in elixir this could have been done in 1-2 hours (no joking). At one point I realized that checking for null pointers every 100 lines of code was not something I wanted to do, so I moved on from golang completely.
The Go community will suggest codegen for this kind of thing. One of the things that I really admire is the portability of Go programs
By the way, Rich, thanks for linking a PDF of Joe’s dissertation! I’ve been meaning to read it for a while and it’s good to be able to stash it on my Calibre server.
© Copyright Elixir Forum | Terms | Privacy & Cookies
