That said, I think the real value of Erlang is the actor model, and specifically, the way it causes you to model things and concepts (or objects, but without the baggage) as isolated processes. This is a direct parallel to the kingdoms of verbs and nouns, but, many OO languages provide isolation for their objects/things/nouns, but not for the processes/verbs. Or rather, the process is not naturally related to the noun, but rather almost an Aspect Oriented programming approach. The actual execution crosses the boundaries of the objects/things/nouns (i.e., a single object's instance being accessed by multiple threads, all contending to modify it; the verbs span the boundary of the noun). But in the actor model, that doesn't happen; you have proper isolation of state (the thing/noun/etc) in the actor, but also isolation of execution (the process/verb) in the actor. That is, one actor = one isolated chunk of both state AND execution.
It's this model that people are looking at when they say it's better at object orientation. I think that's a bit misleading (per other comments), but there's real benefit to it.
"When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like "swearing in church". OOness became something that every respectable language just had to have.
As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully)."
I assume this comes down to a basic equivocation about what "message" really means. In English, it is an asynchronous communication. Whether Alan Kay meant it synchronous, asynchronous, or didn't care, I don't know. But it has never been terribly mysterious to me that the "message passing" in Smalltalk turned into "method calls" in almost every other implementation. I couldn't even tell you what the difference between synchronous message passing and a method call is. Possibly back in the day (had I been around) I could have. But what with all the languages nowadays that have all sorts of semantics for "method calls" you can choose from, I wouldn't know where to draw a line today.
Erlang-style message passing looks to me to be more like what Alan Kay's words were than even Smalltalk was.
In fact, asynchronous messaging seems more in the spirit of "objects being like biological cells and/or individual computers on a network" than a smalltalk-style synchronous message stack.
It's also very easy to use the async/await pattern if you want to make a call, do other work, and get the data from the call at some later point.
It's very common to have blocking API as that's convenient and better hides the implementation details of the API.
Note that the blocking is completely local, it'll simply yield back to the scheduler and some other process will get to run (and BEAM is preemptive so after a number of operations — reductions in BEAM parlance — it's going to deschedule the current process and let something else run even without IO calls).
And of course you can trivially "unblock" the call by creating a wrapper process for that call.
Not every abstraction is object-orientation. The notion of not caring about the internals of something (as with the article's mention that "This is possible because Elixir doesn’t care how the process works internally") is something that goes deeper conceptually and further back in time than objects as we know them.
It might be neat for weaning someone off an overwhelmingly OOP mindset, but that's not what it seems to be trying to do. Instead, it's just demonstrating how to use a new language without it forcing you to think differently, and that's worrying. If every language is a fantastic object-oriented language, why bother using any given one?
Also this fits with my experience with Elixir. I can apply all my OOP baggage very well in Elixir; one active process maps beautifully one object.
The only thing I miss is a clear _terminology_ distinction between the Elixir versions of an object and a class. Both are called processes, which is a bit messy. Strictly a process is just the runtime thing (the "object") and the "class" is just a function (or, in practice, a module that follows a certain convention). But I've heard many people refer to the latter as "processes" too and I'd love a better word.
The article uses Elixir examples, but it is fundamentally about Erlang as that's where the understanding of the concept comes from (through Joe Armstrong), and the examples could just as well have been in Erlang:
> There’s one moment in the episode that surprised me. Joe makes a comment about Erlang being “the most object-oriented language.” The same can be said of Elixir.
This applies to Elixir through Elixir being a syntactic layer over Erlang, not through anything otherwise intrinsic to Elixir.
A process is a function running in its own context.
A module is just a namespace to group some functions. But there is no real link to what an object brings.
At best you could try to compare an OTP behaviour to a class but even that...
I have some ideas for post about the fundamental difference beetween RPC and message passing. And how it impact how you think about your code (Java/Cpp vs Smalltalk/Erlang). I think it is the main point.
That could hardly be less of a fact though.
Kay's thoughts on the matter are in the link below.
I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind
-- Alan Kay, OOPSLA '97
If you are going to Change it At least change it to "Elixir - The Most Object-Oriented Language"
Otherwise a good read. The idea of Elixir/Erlang being "object-oriented" by way of their application of the actor model was one of the "eureka" moments in my transition from procedural languages (in particular, Ruby).