[erlang-questions] object vs. actor (Re: Massive Numbers of Actors vs. Massive Numbers of Objects vs. ????)

[Garrett Smith]

On Wed, Feb 29, 2012 at 5:11 PM, Miles Fidelman
<mfidelman@REDACTED> wrote:
> Raoul Duke wrote:
>>
>> hi,
>>
>> question: what is the difference between an actor and an object? i
>> have seen so many different definitions of the things! the words seem
>> to be heavily context-dependent.
>>
>>
> My understanding (and how I differentiate):
>
> - an object encapsulates state and methods, but is not "active" - depending
> on the environment, methods can be invoked by procedure call or message
> passing (it's a chunk of data bound to methods for manipulating that data)
>
> - an actor also encapsulates state and methods, but is "active" - it's a
> running process that's listening for and responding to messages (it's a
> process)
>
> There are, of course, more formal definitions.  Hewitt is sort of the
> definitive source for defining the actor formalism.  Not sure who's his
> counterpart for objects.
>
> What it always comes down to, for me, is flow of control.  Objects just sit
> there, until some thread winds through them, or until triggered by an event.
>  Actor based systems consist of massive numbers of concurrently executing
> processes.  Very different ways of thinking about things at a systemic
> level.
>
> Of course these are only my views - your mileage may vary.

Just my two cents, but I'd take the energy spent here trying to define
"object" and "actor" and start thinking about how you're going to
build the system:

- How do you store the data? (MySQL, MongoDB, Riak, Mnesia, multiple
stores -- the list of options is *huge* and )

- What are you going to write your "business logic" in (Java, Python,
Erlang, all of the above -- I assume your questions here are related
to how suitable Erlang is for the job -- I'd say pretty good based on
what you're looking for)

- How are you going to communicate between nodes / servers / programs?

Looking for a conceptual model is probably not a total waste of time,
but at some point, you'll have to evaluate your options on those three
points based on technical merit.

As far as the "actor" model and massive concurrency, as as been said,
Erlang will give you options that other language environments won't.
You can even call them "objects" and the VM will work just the same :)

Garrett