Hi Jonas, Can you list what the "things Akka implements now" are that Scala actors don't have?
Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér <jbo...@gmail.com> wrote: > > 2009/9/30 Josh Suereth <joshua.suer...@gmail.com>: >> As much as I agree with your decision, it just makes me sad. I know lots >> of people that learned scala for "actors are the way of the future".... I >> think we need to push harder. Hopefully all major projects migrating off >> actors will give EPFL a wake up call? > > This is the reason I created Akka, to have a standard platform for > Actors with all the things one need to write production applications. > Akka already have 4 committers and honestly, looking at the pace EPFL > has had with bugfixing, features etc I think they will have a very > hard time keep up with what the market needs. I have unfortunately > given up up the Scala Actors library. I need the things Akka > implements now and don't have time to wait indefinitely. > >> >> - Josh >> >> On Tue, Sep 29, 2009 at 1:41 PM, David Pollak >> <feeder.of.the.be...@gmail.com> wrote: >>> >>> >>> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck <stuart.roeb...@gmail.com> >>> wrote: >>>> >>>> Apologies if I've missed something obvious but my web search hasn't >>>> turned anything up... >>>> >>>> What are the Scala Actors instability issues? I'm in the process of >>>> doing some major Scala development work and this comment raises >>>> concerns that I'd like to understand. >>> >>> The issues (with the Scala Actors in general and Lift's use of them) are: >>> >>> Scala Actors use a custom version of Doug Leah's Fork/Join library. This >>> was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent >>> stuff should have been used. I was led to understand that this change was >>> made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still >>> contains fork-join. The FJ library has a memory retention issue where it >>> trades memory for non-locking performance and, with many threads in a >>> thread-pool, this leads to out of memory issues. >>> The Scala Actor code is very brittle. >>> See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html >>> The code has not been materially refactored, which means that even in 2.8, >>> there will be significant potential problems with the Actors. Those >>> potential problems have manifest themselves as real problems in 2.7.x. I >>> have spent in aggregate nearly 3 weeks of my time since November 2008 >>> working around the defects in the Actor library. It's easier to have our >>> own Actors (the current Actor library is about 2 days of work on my part and >>> the refactoring of Lift to work with the existing Actor library is another 2 >>> days of work.) >>> EPFL has been generally slow to respond to bug reports. I am very >>> frustrated and quite frankly tired of having to cajole EPFL into responding >>> to defects in one of the premier Scala libraries. >>> >>> I would strongly suggest that you look at Akka. It's got a better view >>> and implementation of Actors than does the standard Scala distribution. Akka >>> includes support for distributed actors, etc. >>> Hope this helps. >>> >>>> >>>> Best, >>>> >>>> Stuart >>>> >>>> On Sep 29, 3:30 am, David Pollak <feeder.of.the.be...@gmail.com> >>>> wrote: >>>> > Folks, >>>> > >>>> > Given the continued instability of Scala Actors, I've decided to remove >>>> > them >>>> > from Lift. >>>> > >>>> > Specifically, I'm migrating CometActors to sit on top of Lift's Actors. >>>> > But, you'll also be able to use Akka Actors to power Lift's >>>> > CometActors. >>>> > Specifically, I'm working with Jonas to make sure that we share a >>>> > common >>>> > interface to Actors. >>>> > >>>> > I've gotten Lift nearly completely migrated over to Lift's Actors on >>>> > the >>>> > dpp_wip_actorize branch. >>>> > Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize >>>> > >>>> > There will be some breaking changes to your applications. >>>> > Specifically: >>>> > >>>> > - Box will be moved to a new package, net.liftweb.base (this is >>>> > where the >>>> > interface for Actors will live as well) >>>> > - If you make any assumptions about your CometActors being Scala >>>> > Actors >>>> > (e.g., using linking), you will have to rewrite this code >>>> > - Some methods in Lift that currently take Scala Actors as >>>> > parameters >>>> > will take Lift Actors (e.g., ActorPing) >>>> > >>>> > There will be a parallel Maven repository with the new Lift Actor stuff >>>> > in >>>> > it so you will be able to build you apps against the new code before >>>> > the >>>> > official switch-over. >>>> > >>>> > Milestone 6 (which should be out next week) will be based on the >>>> > existing >>>> > Actor model. After we get feedback from the community about the new >>>> > Actor >>>> > stuff, we will switch -SNAPSHOT over to the new Actor stuff. >>>> > >>>> > Questions, thoughts, or comments? >>>> > >>>> > Thanks, >>>> > >>>> > David >>>> > >>>> > -- >>>> > Lift, the simply functional web frameworkhttp://liftweb.net >>>> > Beginning Scalahttp://www.apress.com/book/view/1430219890 >>>> > Follow me:http://twitter.com/dpp >>>> > Surf the harmonics >>>> >>>> >>> >>> >>> >>> -- >>> Lift, the simply functional web framework http://liftweb.net >>> Beginning Scala http://www.apress.com/book/view/1430219890 >>> Follow me: http://twitter.com/dpp >>> Surf the harmonics >>> >>> >> >> >> > >> > > > > -- > Jonas Bonér > > twitter: @jboner > blog: http://jonasboner.com > work: http://crisp.se > work: http://scalablesolutions.se > code: http://github.com/jboner > code: http://akkasource.org > > > > -- Bill Venners Artima, Inc. http://www.artima.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
