I have heard that actors such as used by Apple are slow. Is this true in general?
On Fri, Jul 26, 2013 at 9:13 AM, Matthew Browne <[email protected]> wrote: > Hi Tristan, > Thanks for the clarification. > > I was wondering, do you think it might be useful to implement Actors using > the fibers module (https://npmjs.org/package/fiber)? > > I noticed that there's an Actors lib for Ruby implemented with fibers: > https://github.com/tarcieri/revactor > > It seems like this might make concurrent programming a bit easier in > node.js and help avoid callback pyramids. What do you think? > > Thanks, > Matt > On Jul 25, 2013 2:15 PM, "Tristan Slominski" <[email protected]> > wrote: > >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/iHSkdmGaRnk/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > -- > 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. > > > -- -- 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.
