Would you say that Elixir implements some or all of Alan Kay's definition of object-oriented design?

Some rando called “Joe Armstrong” has said the same thing:

Joe Armstrong: Erlang has got all these things. It’s got isolation, it’s got polymorphism and it’s got pure messaging. From that point of view, we might say it’s the only object oriented language

Ralph Johnson: The thing about Erlang is that it’s in some sense 2 languages, at least you program it 2 levels because one is the functional language that you use to write a single process and then there is what you think about all these processes and how do they interact, one process is sending messages to the other. At a higher level, that Erlang is object oriented, at the lowest level it’s a pure functional language and that’s how it got advertised for a long time.

Ralph Johnson, Joe Armstrong on the State of OOP - InfoQ ~7m30s

(Elixir was not out at this time.)

If we were to put abominations like inheritance aside from classical OOP languages, elixir/erlang abstractions (namely genservers) are not that different from a class in let’s say java. Message passing actually is a solution to a thing that was solved differently by languages like java, concurrency.

All processes(objects) in elixir/erlang are already a concurrent entity, in contrast to an object in java, that is a data structure (state machine). These are 2 different views regard to concurrency, one says that it is better to have small concurrent ready parts and the other one says that we can have chunks of code that we might want later to make concurrent.

It is easy to understand why languages like java were designed this way, for a very long time all the code would run on a single cpu or core and in terms of that, this approach is much more efficient in both short term and long term.

Now I can’t say for sure, however I think erlang never had in mind (at least at the beginning) the concurrency model to be scaled on multiple cores like we use it today, it was designed to have the fault tolerant nature and small concurrent pieces (processes) with their own memory and communication channel was the way to achieve it. Maybe @rvirding can shed some light on their decissions.

From a performance standpoint, I cringe at the thought of using concurrency to implement abstraction and encapsulation, but it is interesting to see how far you can take this idea. Tony Arcieri (of Celluloid and Revactor fame in Ruby-world) developed a language more than a decade ago called Reia which took this idea to its logical conclusion by implementing something with Rubyish object semantics on top of Erlang by using message passing. I also know that the earliest incarnations of Elixir had more rubyish semantics, don’t know if it was at all similar to this idea; that was before I got involved in 2013.

You can still have oop in elixir: GitHub - wojtekmach/oop: OOP in Elixir! · GitHub

Could you formulate more on that? because as far as I see, elixir/erlang does seem to be a sane scalable solution in a nowadays world of concurrency.

The question of OOP/not-OOP is somewhat irrelevant without considering the context: concurrent isolated entities communicating with each other.

See “Joe Armstrong & Alan Kay - Joe Armstrong interviews Alan Kay” https://www.youtube.com/watch?v=fhOHn9TClXY

And a slide from there:

image1200×908 96 KB

Also, I clean forgot that Alan Kay answered this question on Quora:

I love Joe Armstrong — we lost a great man when he recently left us.

And, he might be right. Erlang is much closer to the original ideas I had about “objects” and how to use them.

However, another way to look at this is to consider “What Is Actually Needed” (WIAN) and realize that much more is needed beyond what we are programming in today.

Joe would most definitely be more in favor of this idea than worrying about what either one of us did decades ago.

When you send a message between processes in Elixir, the data passed as arguments are copied into the heap of the receiving process. When you call a method on a Ruby (or Java, C# apart from unboxed primitive arguments) object, any arguments are passed by a reference, memory is not copied. This makes Erlang more resilient and scalable in the large and avoids complications like concurrent garbage collectors, but in the small there are overheads that do not exist in traditional systems. Also these are not the only overheads; when objects are bound to processes in this way, they can become a bottleneck, and they introduce more complicated failure modes (which Elixir/BEAM is well equipped to manage, but they still exist).

These are some of the reasons why we don’t advise people to use GenServer as a general abstraction method in Elixir, but to only use it when concurrency is actually one of the problems to be solved, rather than a mechanism for solving unrelated software design problems.

To be fair, while this is better for performance it’s also one of the things, which causes a lot of grief with OOP. You not only have a lot of stateful stuff, but also seemingly everybody has access to public state all the time.

I totally agree with you from the performance standpoint, however I want to introduce another point: software resilience in context of the development. Languages like c#, java, ruby offer those optimizations on behalf of development complexity.

While this is kind of a stupid argument from an engineering point of view, I could argue that nowadays the ability to write resilient software with minimal investments (developers and time) is as important if not more important than performance.