I think the assumption that processes+protocols are preferred in Erlang is flawed. If processes and protocols were the way to go in Erlang, we wouldn’t have a gen_server (which is a functional API) as the default way to build processes in Erlang/OTP and used by the majority of the Erlang community.

I believe Joe would like to move more towards processes and protocols and I personally would like to see it explored but we do need some additions in order to make it more productive (and Joe explores some of them in his thesis).

Dave’s approach is functional. A lot of the discussion was when your functional API should be backed by processes or not.

I think both communities would generally agree to not create processes when they’re not necessary. Dave even says so in the readme of his component library:

If you don’t share your state with anybody then good news, you don’t need processes and you don’t need this library (for now). You will live a happier life than the rest of us.

Similarly, Joe is not arguing to use processes for everything. He is arguing to not hide our processes behind GenServer, components, etc. Perhaps they both want to achieve the same goal, which is to streamline the development experience related to processes, but they are approaching the problem in two different ways.

PS: I renamed the title because this is not a discussion about Erlangers vs Elixirists.

I’m sure he’s going to chime in when he has some time but for the time being I’ll just express my impression as a reader of the book.

There is an expectation that a reader of Elixir in Action may have some OO background and the essence of the message that I received is:

• Choosing boundaries for processes is different from choosing boundaries for objects/classes.

In particular:

• Processes are units of computation, messages implementing protocols are coordination - i.e. there is a very clean separation between the computational model and coordination model.

• OO designed according to CRC leads to very different boundaries for Objects/Classes primarily motivated by encapsulation and while collaboration can be seen as a form of coordination, collaboration tends to happen primarily in the computational domain.

While both have state, processes and objects (classes) are even more different than apples and oranges.

Aside: Process and Stateness are they object? - #8 by peerreynders

It feels like you’re takeing the advice @sasajuric has a little to far into a black-or-white area of thinking. From my experience people frown upon using processes for code organisation purposes or data hiding. What processes are advocated for is rather for runtime behavior like isolating errors and organising parts of your system into supervision trees, which allow you to define which parts of your applications can fail independently and which parts need to fail together (e.g. cleanup is needed). Another runtime behavior a process gives you is serialization of requests.