In this context, implementing actors can be thought of as a pattern. I've implemented actor frameworks from scratch on a number of different "substrates". Much like one can implement a JVM in JavaScript, one can implement an actor system on top of Node.js. All the way down, something must animate the actor framework. All the way down, things tend to run in assembly on hardware. How many layers between the hardware and your actor framework and what conveniences you want to include with that are up to you.
Another way to phrase the issue, an actor framework can be a meta-layer on top of Node.js reactor setup. If the use of actors helps to reason about the problem in better ways, that's part of the cost benefit analysis of solving the problem with actors. You could also go as far as Coffeescript did and implement an [actor] language using Node.js' reactor, I'd probably use OmetaJS here. Lastly, my usual criticism, Akka (inspiration behind drama) is popular, but it gives up Object Capability, which actor systems start off with. Object Capability allows you to _prove_ (as in mathematical proof) security properties of an actor configuration. Framework implementations of actors tend to sacrifice Object Capability for, in my opinion, dubious benefit. On Wednesday, July 24, 2013 12:17:24 AM UTC-5, Matthew Browne wrote: > > Hi, > I realize this thread is a little old, but I just came across it I don't > understand your reasoning...yes, Reactor (event loop-based approach) is a > different approach than Actors, but Actors have been implemented > successfully on top of event loops in some other languages like Python and > have achieved very good concurrent performance (from what I can gather > anyway). > > The main drawback is that you no longer have parallelism across multiple > cores, but in node.js we've already accepted that and are willing to settle > for separate OS processes instead. > > The only real disadvantage I can think of is that the node.js API is > designed to be used with callbacks, but for one's own application code > (especially the parts that are straight JS that don't use the node API as > much) it seems like an actors library like drama > <https://github.com/stagas/drama>is a great approach to concurrency (and > asynchronous OOP). > > > On Monday, June 18, 2012 11:50:41 AM UTC-4, Alexey Petrushin wrote: >> >> I'm not sure that Reactor (Node.js) should be used with Actors. It seems >> that it's a different approaches for solving the same problem - concurrency. >> >> If JS would have ability to spawn tons of cheap processes - then we just >> don't need such limitation as Node.js async API. >> >> So, it seems it's not just a question of some sort of lib for node.js - >> but more like a completely different API on top of Node.js (or instead of >> Node.js). >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
