Sending a message to an Erlang / Elixir process to change its internal status (a GenServer) is not conceptually different than calling a method of an object.

The big difference I see between Elixir and (example) Java or Ruby is that everything is an object in those languages but a big Elixir application has only a few GenServers, where keeping a state matters. Everything else is passed as argument, which by the way it's what a GenServer does internally with an endless tail recursion.

In every sense. Prototype-based OO has been a thing for a long time now.

If you look at the entire breadth of OO languages and see what they have in common, there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional.

Prototype-based OO is a form of inheritance.

> there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional.

That's a broader definition than I had in mind, but I can see where you're coming from.

Self doesn’t have classes or inheritance, and it’s as [single-dispatch] OO as they come.

(Certainly moreso than something like C++, which wouldn’t look out of place on a Melanesian island. Never could figure why C++ and all its typed kin would choose to dispatch [dynamically] on only one argument instead of on all. Playing to their weaknesses, no?)

My guess is that by going with single dispatch, you get clear 'ownership' in terms of methods^H^H^H^H^H^H^H member-functions belonging to classes.

Can't say I know a lot about multiple-dispatch though.

Thinking off the top of my head, how about a language that only had interfaces (ala COM)? Implemented by non-inheritable objects, using delegation instead of inheritance to share code.

I imagine some syntax sugar to help with the delegation to make it less cumbersome.