Erlang 参与者与 OOP 对象有何不同？

假设我有一个 Erlang actor 定义如下：

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

同样，我有一个 Ruby 类定义如下：

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

  def increment
    @num += 1
  end
end

Erlang 代码以函数式风格编写，使用尾递归来维护状态。然而，这种差异的有意义的影响是什么？在我天真的眼中，这两件事的接口看起来非常相似：您发送一条消息，状态得到更新，然后您返回新状态的表示。

函数式编程经常被描述为与 OOP 完全不同的范例。但 Erlang actor 似乎完全做了对象应该做的事情：维护状态、封装并提供基于消息的接口。

换句话说，当我在 Erlang actor 之间传递消息时，与在 Ruby 对象之间传递消息时有何不同？

我怀疑功能/OOP 二分法会产生比我所看到的更大的后果。有人能指出吗？

让我们先抛开 Erlang actor 将由 VM 调度的事实，因此可以与其他代码同时运行。我意识到这是 Erlang 和 Ruby 版本之间的主要区别，但这不是我的意思。其他语言（包括 Ruby）也可以实现并发。虽然 Erlang 的并发性可能表现得非常不同（有时更好），但我并不是真正询问性能差异。

相反，我对问题的功能与 OOP 方面更感兴趣。

换句话说，当我在 Erlang actor 之间传递消息时，与在 Ruby 对象之间传递消息时有何不同？

不同之处在于，在像 Ruby 这样的传统语言中，没有消息传递，而是在同一线程中执行的方法调用，如果您有多线程应用程序，这可能会导致同步问题。所有线程都可以访问彼此的线程内存。

在 Erlang 中，所有 Actor 都是独立的，更改另一个 Actor 状态的唯一方法是发送消息。任何进程都无法访问任何其他进程的内部状态。