[erlang-questions] object vs. actor (Re: Massive Numbers of Actors vs. Massive Numbers of Objects vs. ????)
Thu Mar 1 17:53:33 CET 2012
Garrett Smith wrote:
> 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:
well duh.. :-)
questions/discussion here are about trying to bounce concepts off
people, and try to uncover technologies that are not all that visible
> - 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
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 erlang as well (I'm pretty sure Couch supports embedded erlang
> - 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.
- 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.
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions