Message passing in Java is basically joined at the hip with method calls, at least in the same thread. On new Foo(), you call .bar(), and then block until you get a response. Because you know .bar() is there before you ever call it, it's not super obvious what the message passing is.
Now imagine something like Erlang, which is a complete mind screw for someone used to writing sync code. The FooProcess can send the BarProcess an async message, but there is no guarantee the message got to BarProcess recieved the message, or that the BarProcess or that it will even be alive when the message arrives.
Maybe a good place to start is to read up on method_missing and message passing in Ruby.
Why would you ever want this kind of uncertainty in-process? If I have an object that lives in my process and I want to call a function on it, I rely on the compiler to tell whether that function exists or not. If it doesn't, why would I ship with code that will never work?
If we're talking remote calls, sure, there is never any guarantee that the recipient has that method, or that it's even listening anyway.
All of that to say that that whole discussion between function call or message passing is a waste of time and irrelevant in programming.
There must be a better way to discuss this topic than to just shit all over something that other people think is a good idea, no? How can you know with such certainty that you're correct and everyone else is just being stupid?
EDIT: Err, never mind. You're apparently inclined to shit on anything you don't like in most of your comments.
> All of that to say that that whole discussion between function call or message passing is a waste of time and irrelevant in programming.
I once felt that way. Then I learned Elixir, and the actor model is my favorite thing of all time. It has amazing abstractions for dealing with concurrency.
Consider that the call-site in Ruby in the general case does not have any guarantees about how the recipient of a message will act on the message.
As an implementer, as you of course know from the amazing optimizations Truffle Ruby does, there are certainly lots of special cases where you can aggressively decide from an implementation point of view that you know how the recipient will act. So in practical terms a lot of code that uses systems that conceptually can do message passing will in practice in many - or even most - cases act exactly the same as a pure method-calling system.
But the conceptual difference is that in a message passing system, you can not do so for the general case before execution starts, because there is the chance that the treatment of messages change dynamically at runtime. E.g. the "fun" case of a program that eval()'s a user supplied string that redefines a method, to take the extreme case. "pry" and "irb" are good examples...
To me at least, message passing and "extreme late-binding of all things" relate to systems that conceptually allow deferring the decision of which piece of code will get called until the moment a message is passed, whether or not a specific instance actually makes use of that flexibility, while a "method call" implies that you can know in the general case by static analysis which method will be invoked, or at the very least which of a small, constrained set of methods will be invoked.
Of course you can always emulate one with the other, so the boundaries gets fuzzy.
EDIT: Put another way: You can implement message passing in any system by defining a send(object, ... args) function that implements dynamic lookup and allows the program to modify the lookup at runtime. One step up is to implement a "send(...args)" method on a class in a C++/Java style OO system. So any system can have message passing. But the difference in whether or not we consider a system message passing is largely a question of whether or not the system provides syntactic sugar to make that easy and whether or not it is considered idiomatic use.
Re: method_missing, I supoose it's not as easy to understand as I thought, which is to say if I understood it better, I could explain it better. The best I can do is this...
1. A typical method call in Java means "I pass a message (args) to a method on some object, and block until I get a response", which usually means building of up stack of blocking calls waiting for a response". The message passing is sending the message, which in Java is tightly coupled to receiving the response.
2. In Erlang, you might have a process (think of it as an object for this example [1]), that sends a message to another process. The sending process doesn't need to wait for a response. Erlang does have function calls that feel pretty much exactly like method calls in Java, and then there is message passing between processes, and that separation makes the differences more clear to me, which is not to say I understand things correctly.
3. method_missing in Ruby is kind of like sending a letter in the mail to Santa Clause. There is no physical address for Santa (aka an undefinded function), but someone at the post office looks at the intended destination (SantaClause.mailing_address) of the North Pole and message itself ("I have been good, and want a Nitendo Swith for Xmas"), and determines how to respond (method_missing) to the message.
I do not know if this explanation is any good, so please be kind :) Doing my best!
Now imagine something like Erlang, which is a complete mind screw for someone used to writing sync code. The FooProcess can send the BarProcess an async message, but there is no guarantee the message got to BarProcess recieved the message, or that the BarProcess or that it will even be alive when the message arrives.
Maybe a good place to start is to read up on method_missing and message passing in Ruby.