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

[Garrett Smith]

On Thu, Mar 1, 2012 at 10:53 AM, Miles Fidelman
<mfidelman@REDACTED> wrote:
> Garrett Smith wrote:
>
>> - How do you store the data? (MySQL, MongoDB, Riak, Mnesia, multiple
>> stores -- the list of options is *huge* and )
>
> would sort of be nice to store data as simply a large cloud of Erlang
> processes - hence inquiries and discussion here
>
> but, at least in the short term, most likely is CouchDB for early versions
> (has most of the characteristics I'm looking for), though some possibility
> of using eXist (XML document store, with APP/Atom interfaces already
> available)
>
> probably leverage an erlang web framework (Yaws, Mochiweb, Nitrogen)
>
>> - 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)
>
> embedded in documents, i.e., Javascript embedded in HTML/XML; possibly
> embedded erlang as well (I'm pretty sure Couch supports embedded erlang
> scripts)

Ah! See comment below.

>> - How are you going to communicate between nodes / servers / programs?
>
> protocol based - XMPP or Atom/APP, with support for message based protocols
> as well (SMTP, NNTP, possibly IMAP for access)
>
>> 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.
>
> I've generally found it useful as a way to organize thinking.
>
>> As far as the "actor" model and massive concurrency, as as been said,
>> Erlang will give you options that other language environments won't.
>
> Absolulutely, but it doesn't quite go as far as I'd like.  Erlang is great
> for massive concurrency, not so great if you want huge numbers of processes
> to persist, perhaps permanently.

Erlang processes aren't persisted, but their state can be, quite easily.

If the "business logic" associated with your entities/documents is
expected to change so often that you want to store it as a part of the
document itself, Erlang offers some excellent options.

A trivial example, in an Erlang shell:

1> Add = fun(X, Y) -> X + Y end.
2> Add(10, 10).
100
3> file:write_file("addfun", term_to_binary(Add)).
4> init:stop().

And restart Erlang shell:

1> {ok, Bin} = file:read_file("addfun").
2> Add = binary_to_term(Bin).
3> Add(10, 10).
100

You don't need CouchDB here -- just store your "logic" off in the
database of your choice -- or as a base64 encoded blob in your
document!

> Our application will be distributing HTML+Javascript documents by email -
> message like, but also object-like and actor like when live in a client or
> browser.  The question is how to maintain the actor-like behavior when
> filing away large numbers of emails.
>
> It would be interesting to simply store each message as an erlang thread,
> accessed through message passing.  But that doesn't scale with current
> technology.  The short term answer is clearly to use a database of some
> sort, but a longer solution would be to find ways to support large numbers
> of hibernating processes.
>
>> You can even call them "objects" and the VM will work just the same :)
>>
> I could call them that, but erlang does NOT support object-oriented
> programming in the sense of inheritance and so forth.

If you're planning to store "code" with these documents, using
side-effect free functions is a Very Good Idea, IMO.

Btw, off topic, but this is an interesting take on OO (note the author):

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

Garrett