Well, Armstrong may have been exposed to C++-style OOP like many (most?) programmers, which would of course lead him to believe that Erlang was very different from C++'s OOP. But languages that really orient toward object orientation rather than a thin semantic layer over procedural programming look a lot more like Erlang. Take Smalltalk for example: Smalltalk objects talking to each other looks almost identical to Erlang threads talking to each other.
Yes, it absolutely is. But I do understand what imagist is getting at; if you read about what Smalltalk is supposed to be and you read Alan Kay's description of what OO is supposed to be, but you don't use Smalltalk yourself, it is easy to think that Erlang is exactly what he was talking about.
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.
That is an enormous amount of difference, but one which seems entirely irrelevant to Kay's description of object-orientation.
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.
Question about elixir: In the article's example, it looks like the HTTP.get function call is turning the asynchronous message into a blocking call. Is that common in elixir/erlang, for libraries to provide blocking utilities?
Yes, it's quite common for Elixir libraries to provide blocking calls. If your program is well-designed though, the calling process will be "blocked" but other processes will be executing at the same time. So having a process waiting on a HTTP call has no impact on the overall performance of the system. This is one of the big reasons why Erlang/Elixir's model of having many processes is awesome.
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.
> Is that common in elixir/erlang, for libraries to provide blocking utilities?
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.
