You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by David Pollak <fe...@gmail.com> on 2009/05/23 17:58:33 UTC

Re: [Lift] Re: New Lift Actor code

On Sat, May 23, 2009 at 7:39 AM, Martin Ellis <el...@gmail.com> wrote:

>
> On Sat, May 23, 2009 at 6:19 AM, David Pollak
> <fe...@gmail.com> wrote:
> > I am happy to share the Lift Actor code with EPFL and if it makes it into
> > the Scala distribution as SimpleActors or something similar, I'm totally
> > cool with that.  I'm not interested in owning or maintaining an Actor
> > library.  I am however, dedicated to making sure that Lift apps can run
> in
> > production for months (or even years) without retaining memory or having
> > other problems that can impact the stability of applications.
>
> The cool thing about this is that it provides solid evidence that Scala -
> as a language - does satisfy the aim of being be a scalable language.


Yes, this is absolutely right.  It also points up what I missed in my
original posting... the amazing value of the Scala Actors which include:

   - First, and most important to Lift, a conceptual framework for doing
   concurrency.  Without the Actor model, Lift would not have such a rich model
   for building interactive applications.
   - A design that keeps true to the Erlang Actor model in that it supports
   linking, run states, and other things that make an OTP style library
   possible. (Hey Jonas, where's that OTP library?)
   - A design that has evolved from simply supporting send/wait-for-response
   (!?) to send and immediately receive Future and other cool features.
   - Blocking until Futures are satisfied without consuming a thread if the
   Future was within a react-based Actor.
   - An implementation that worked well in JDK 1.4.  Many of the current
   memory and scheduling issues are a result of the fact that Scala's Actors
   worked on JDK 1.4, back when 1.4 was the target for the Scala distribution.

Scala is a language that supports multiple Actor libraries, just as it
supports multiple collections libraries.  There are no built-in collections
classes in Scala.  All collections are implemented at the library level.
And just as there were defects in some on the Scala collections classes that
David MacIver fixed, there are existing defects in the Actor libraries.
Just as there are specialized Map() collections that are appearing for Scala
that maximize performance for particular data types and/or key
distributions, we are creating a specialized Actor library that's optimized
for the kind of use that we see in Lift and web apps in general.

This is a testament to Scala's flexibility and to the foresight of including
such a powerful concurrency library, Actors, as part of the distribution.
But for those two things, Lift would not be nearly as cool as it is.

So, please do not read this thread as a repudiation of the Scala Actor
library, please read it as an expansion of what is possible within Scala.

Thanks,

David


>
>
> I'm referring to the fact that Scala actors are not part of the core
> language.
> They're just a library that can be replaced with a different library, which
> can
> also to provide the 'feel' of native language support for objects of that
> type.
> It's such a fundamental part of the language design that Programming in
> Scala talks about it in Chapter 1, Section 1.
>
> It's timely that you sent the email so soon after the link to the Guy
> Steele
> "Growing a Language" OOPSLA presentation (of which I am still in awe)
> went around on twitter.
> http://video.google.com/videoplay?docid=-8860158196198824415
>
> I guess this demonstrates that Scala provides the features for growth that
> Steele says are needed for languages to be successful in the long term,
> and that he would have liked Java to have.  Awesome.
>
> Nice, clear explanation, by the way.  Should avoid any any NIH allegations
> on
> the diggs and reddits of the world ;o)
>
> Martin
>
> --~--~---------~--~----~------------~-------~--~----~
> 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+unsubscribe@googlegroups.com<li...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Re: [Lift] Re: New Lift Actor code

Posted by Jonas Bonér <jb...@gmail.com>.
> First, and most important to Lift, a conceptual framework for doing
> concurrency.  Without the Actor model, Lift would not have such a rich model
> for building interactive applications.
> A design that keeps true to the Erlang Actor model in that it supports
> linking, run states, and other things that make an OTP style library
> possible. (Hey Jonas, where's that OTP library?)

Here it is the repo:
http://github.com/jboner/scala-otp/tree/master

Or do you mean that it has not happened much there for a while?
I certainly plan to expand it quite a lot, even have some code I could
make its way into it eventually.

-- 
Jonas Bonér

twitter: @jboner
blog:    http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner