How do Erlang actors differ from OOP objects?

Question

Suppose I have an Erlang actor defined like this:

counter(Num) ->
  receive
    {From, increment} ->
      From ! {self(), new_value, Num + 1}
      counter(Num + 1);
  end.    

And similarly, I have a Ruby class defined like this:

class Counter
  def initialize(num)
    @num = num
  end

  def increment
    @num += 1
  end
end

The Erlang code is written in a functional style, using tail recursion to maintain state. However, what is the meaningful impact of this difference? To my naive eyes, the interfaces to these two things seem much the same: You send a message, the state gets updated, and you get back a representation of the new state.

Functional programming is so often described as being a totally different paradigm than OOP. But the Erlang actor seems to do exactly what objects are supposed to do: Maintain state, encapsulate, and provide a message-based interface.

In other words, when I am passing messages between Erlang actors, how is it different than when I'm passing messages between Ruby objects?

I suspect there are bigger consequences to the functional/OOP dichotomy than I'm seeing. Can anyone point them out?

Let's put aside the fact that the Erlang actor will be scheduled by the VM and thus may run concurrently with other code. I realize that this is a major difference between the Erlang and Ruby versions, but that's not what I'm getting at. Concurrency is possible in other languages, including Ruby. And while Erlang's concurrency may perform very differently (sometimes better), I'm not really asking about the performance differences.

Rather, I'm more interested in the functional-vs-OOP side of the question.

Answer 1

In other words, when I am passing messages between Erlang actors, how is it different than when I'm passing messages between Ruby objects?

The difference is that in traditional languages like Ruby there is no message passing but method call that is executed in the same thread and this may lead to synchronization problems if you have multithreaded application. All threads have access to each other thread memory.

In Erlang all actors are independent and the only way to change state of another actor is to send message. No process have access to internal state of any other process.