> Akka system As far as I know Akka isn't true actor framework. It offer two ways
- Actors backed by threads - simple to use, but not good for performance - Asynchronous actors - good performance but hard to use (same async stuff, with same callback hell and other problems). True actor - when you have both - synchronicity and performance, Akka can't provide it. On Wednesday, September 25, 2013 5:32:23 PM UTC+4, ajlopez wrote: > > Interesting thread, lot of good resources and discussion > > Since my past year email, I updated my pet project, to reflect more a > (very) simplified Akka system: > > https://github.com/ajlopez/SimpleActors > > Angel "Java" Lopez > @ajlopez > > > > On Wed, Sep 25, 2013 at 10:25 AM, Matthew Browne > <[email protected]<javascript:> > > wrote: > >> On 9/25/13 9:06 AM, Alexey Petrushin wrote: >> >> I'd personally prefer actor to reactor because it's simpler to use. For >> me working with isolated independent things is much simpler than with state >> machine and recursions. >> >> I agree. Events can help prevent callback pyramids to some degree, but >> with actors you can write code just as if it were synchronous; it's just >> simpler. >> >> In terms of the API for a new actors library for node.js, I was thinking >> of something similar to this Ruby library: >> http://celluloid.io/ >> >> That library uses threads, but the same author previously wrote a library >> implemented using fibers, which could serve as a model for node.js (since >> obviously we don't have or want threads): >> https://github.com/tarcieri/revactor >> >> On 9/24/13 1:56 PM, Norman Paniagua wrote: >> >> Thanks for the resources… >> >> I read somewhere in this groups that c extensions may slow down nodejs, >> and fibers just is written in c++, don't know yet how it may affect the >> performance of the app that uses it. >> >> Thanks for mentioning this. There's at least one significant framework >> already using fibers (Meteor) and I haven't heard anything about it being >> slow, but we should keep this in mind because it would be ideal if the >> actor library were just as fast as native node.js. >> >> >> On Wednesday, July 24, 2013 9:17:24 AM UTC+4, 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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] <javascript:>. >> >> 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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] <javascript:>. >> 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.
