It's a polyglot world after all

[David Pollak]

Last week, I had a bunch of really excellent conversations with folks about Lift, Scala, fabric computing, scalable storage, etc.  One of the big take-aways from the conversation was that any system, web framework, fabric computing infrastructure, etc. cannot be Scala-only.  While Scala is a tremendously powerful and excellent language, it is too much of barrier to entry for many folks to switch to Scala just to adopt the likes of Lift.

With those ideas rumbling around in my brain, I had coffee with @KirinDave and the San Francisco BankSimple folks.  Our conversation quickly traversed 5 different languages.  The BankSimple folks are clearly top 1% developers and they are a polyglot shot... they choose the best language for the particular task.  Following the coffee, I got a a conference call with one of my clients (my first non-Scala project in over 2 years.)  During the call, it struck me light a bolt of lightening... it'll be 10+ years before the mainstream corporate developers (and they are the ones with money) adopt Scala... they're currently swallowing Ruby and having a not-great time of it.

I realized Lift had to broaden outside of Scala.

I went home and did a quick research spike on Lift to see how hard it would be to make Lift easily usable from Java.  Well, Lift is marginally usable from Java, but the code is, well, ugly Java code.  Once Java8 supports lambdas, using Lift from Java will be cleaner.

Next, I did a quick research spike in JRuby... and holy cow, with the exception of a few things (symbolic method names, singletons, implicit parameters/CanBuildFrom, and var-args) Lift is reasonably usable from JRuby (except for pattern matching... but we'll get to that issue in a minute).

I spent the last few days working on the JRuby codebase to address the above list of issues and I'm about half way done (see https://github.com/jruby/jruby/tree/scala )

I've also recruited a most awesome hard-core Ruby/Rails developers (Aaron Blohowiak http://twitter.com/#!/aaronblohowiak ) to help design the Lift Ruby APIs... because they have to be different from the Lift Scala APIs.  And where Lift uses a lot of Scala's pattern matching, we will work on a Ruby DSL to achieve the same thing, except in the Ruby Way.

To pro-actively answer some questions:

• No, Lift is not abandoning Scala... the core parts of Lift will always be written in Scala... it's my favorite language and it's a powerful language for expressing the kind of semantics that have made Lift powerful and different.
  
• Why would someone use Lift with JRuby when they can use Rails?  Lift is hands-down the best web framework available today.  It's got better semantics for Comet and Ajax than any other web framework.  It's more secure by default than most other web frameworks.  Lift-based apps scale nicely.  Lift apps are more concise than most other web apps.  Put another way, if you're a Ruby developer looking for a more secure, more scalable web framework that allows you to build more interactive apps, Lift is it.
• What other languages will Lift support? Initially, it'll be JRuby... once we get the JRuby APIs nice and clean, we'll look around for the next language to support.  Maybe it'll be mainstream Java (if we can solve API issues like pattern matching in Ruby, maybe a better answer will come along for Java).  Maybe it'll be Clojure.  But whatever the next language on the Lift polyglot tour, it'll feel native to that language (even if that means annotations in Java... gaaakkk).
• Will this derail the Lift documentation efforts?  No, just the opposite, as we work through the APIs, I plan to document them much more cleanly.

So, what needs to be done on the Lift side to support JRuby:

1. Snippets — invoking a Ruby script
2. Support for box/option (this may be as simple as making Box implement java.lang.Iterable)
   
3. S, SHtml, LiftRules
4. Boot
5. SiteMap
6. SessionVar/Vars
7. Helpers
8. CSS Selector Transforms
9. Alternative to pattern matching

The above is the list of the key parts of Lift that we have to build nice Ruby APIs for.

I look forward to broadening Lift's reach and making the power of Lift available to a broader and broader audience.  I look forward to the Lift community welcoming folks outside the core Scala community.

[work only]

Hi 

I know you want Lift to be used by more people and I do understand about business not support Scala, but once its compile its just bytecode.

I just feel a bit sad don't know why, I do hope that the documentation and video training down don't slow down.

Best Regards

Paul

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Indrajit Raychaudhuri]

On Wednesday 12 January 2011 at 10:04 AM, work only wrote:

Hi 

I know you want Lift to be used by more people and I do understand about business not support Scala, but once its compile its just bytecode.

Obviously, David can answer better, but my feeling is contrary. Broadening a framework to adapt to more language profits all and adaptation grows at faster rate.

For example, in the context of Lift Modules discussion, modules can be eventually be written either in Scala, Java or JRuby and they all work in a homogeneous environment of Lift ;) 

- Indrajit

[Indrajit Raychaudhuri]

So *this* is what had been brewing over the last week. Fantastic!

- Indrajit

[Derek Chen-Becker]

Looks like 2011 is going to be yet another wild ride (in a good way) ;)

[work only]

Yep it's good for Lift :)

Just diehard Scala supporter :)

Paul

[Joseph Stein]

How about the backend support effort? Model? Record? 10) & 11) ?

Is there any room for more help towards this?

/*
Joe Stein
http://www.linkedin.com/in/charmalloc
Twitter: @allthingshadoop
*/

[Maarten Koopmans]

My 2 cents: it's a good path, as long as it doesn't prevent Lift from
staying head and shoulders above the competition. More traction =
good, just like jRuby exists next to Ruby. As a joke... I'd call the
port lambda the ultimate at first :-)

And as an aside: I founded a start up (rightfabric) last year that
focuses on PAYG cloud backed storage fabrics for everyone, with all
code written in Scala and the web part now being done in Lift.
Rationale: sophisticated stuff needs sophisticated tools and a smart
community that is large enough (in stead of the mediocre people I
could get elsewhere). When we go private beta at the end of Q1 I'll be
sure to prioritize people here that are interested in a few GB free
online storage.

Ping if you are interested already.

Anyway, keep up the good work, also on the Scala side.

--Maarten

On Wednesday, January 12, 2011, Joseph Stein <cryp...@gmail.com> wrote:i

> How about the backend support effort? Model? Record? 10) & 11) ?
> Is there any room for more help towards this?
>
> /*
> Joe Stein
> http://www.linkedin.com/in/charmalloc
> Twitter: @allthingshadoop
> */
> On Tue, Jan 11, 2011 at 11:14 PM, David Pollak <feeder.of...@gmail.com> wrote:
> Last week, I had a bunch of really excellent conversations with folks about Lift, Scala, fabric computing, scalable storage, etc.  One of the big take-aways from the conversation was that any system, web framework, fabric computing infrastructure, etc. cannot be Scala-only.  While Scala is a tremendously powerful and excellent language, it is too much of barrier to entry for many folks to switch to Scala just to adopt the likes of Lift.
>
> With those ideas rumbling around in my brain, I had coffee with @KirinDave and the San Francisco BankSimple folks.  Our conversation quickly traversed 5 different languages.  The BankSimple folks are clearly top 1% developers and they are a polyglot shot... they choose the best language for the particular task.  Following the coffee, I got a a conference call with one of my clients (my first non-Scala project in over 2 years.)  During the call, it struck me light a bolt of lightening... it'll be 10+ years before the mainstream corporate developers (and they are the ones with money) adopt Scala... they're currently swallowing Ruby and having a not-great time of it.
>
> I realized Lift had to broaden outside of Scala.
>
> I went home and did a quick research spike on Lift to see how hard it would be to make Lift easily usable from Java.  Well, Lift is marginally usable from Java, but the code is, well, ugly Java code.  Once Java8 supports lambdas, using Lift from Java will be cleaner.
>
> Next, I did a quick research spike in JRuby... and holy cow, with the exception of a few things (symbolic method names, singletons, implicit parameters/CanBuildFrom, and var-args) Lift is reasonably usable from JRuby (except for pattern matching... but we'll get to that issue in a minute).
>
> I spent the last few days working on the JRuby codebase to address the above list of issues and I'm about half way done (see https://github.com/jruby/jruby/tree/scala )
>
> I've also recruited a most awesome hard-core Ruby/Rails developers (Aaron Blohowiak http://twitter.com/#!/aaronblohowiak ) to help design the Lift Ruby APIs... because they have to be different from the Lift Scala APIs.  And where Lift uses a lot of Scala's pattern matching, we will work on a Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
> No, Lift is not abandoning Scala... the core parts of Lift will always be written in Scala... it's my favorite language and it's a powerful language for expressing the kind of semantics that have made Lift powerful and different.
> Why would someone use Lift with JRuby when they can use Rails?  Lift is hands-down the best web framework available today.  It's got better semantics for Comet and Ajax than any other web framework.  It's more secure by default than most other web frameworks.  Lift-based apps scale nicely.  Lift apps are more concise than most other web apps.  Put another way, if you're a Ruby developer looking for a more secure, more scalable web framework that allows you to build more interactive apps, Lift is it.
>
> What other languages will Lift support? Initially, it'll be JRuby... once we get the JRuby APIs nice and clean, we'll look around for the next language to support.  Maybe it'll be mainstream Java (if we can solve API issues like pattern matching in Ruby, maybe a better answer will come along for Java).  Maybe it'll be Clojure.  But whatever the next language on the Lift polyglot tour, it'll feel native to that language (even if that means annotations in Java... gaaakkk).
>

> Will this derail the Lift documentation efforts?  No, just the opposite, as we work through the APIs, I plan to document them much more cleanly.So, what needs to be done on the Lift side to support JRuby:
> Snippets — invoking a Ruby scriptSupport for box/option (this may be as simple as making Box implement java.lang.Iterable)
> S, SHtml, LiftRulesBootSiteMapSessionVar/Vars
>
> Helpers
> CSS Selector TransformsAlternative to pattern matchingThe above is the list of the key parts of Lift that we have to build nice Ruby APIs for.

[Antonio Salazar Cardozo]

Wow. This is epic. I can't wait to see the fruits of this labor. I've slowly come to love Scala at least on the same level if not more than Ruby, but I can definitely envision a world where certain parts (maybe snippets) are a better fit for Ruby and others (e.g. actors) are a better fit for Scala.

This really is bringing Lift to the next level.

Antonio

[Mads Hartmann Jensen]

This is super exciting! Very nice start of 2011 for Lift :)

Sent from my iPhone

[Lukasz Kuczera]

Sounds very exciting. How about compatibility, new changes could be
harder to implement. Would it be possible to write some abstraction
layer on top of that.

> Blohowiakhttp://twitter.com/#!/aaronblohowiak) to help design the Lift

> Ruby APIs... because they have to be different from the Lift Scala APIs.
> And where Lift uses a lot of Scala's pattern matching, we will work on a
> Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
>

>    - No, Lift is not abandoning Scala... the core parts of Lift will always

>    be written in Scala... it's my favorite language and it's a powerful
>    language for expressing the kind of semantics that have made Lift powerful
>    and different.

>    - Why would someone use Lift with JRuby when they can use Rails?  Lift is

>    hands-down the best web framework available today.  It's got better
>    semantics for Comet and Ajax than any other web framework.  It's more secure
>    by default than most other web frameworks.  Lift-based apps scale nicely.
>    Lift apps are more concise than most other web apps.  Put another way, if
>    you're a Ruby developer looking for a more secure, more scalable web
>    framework that allows you to build more interactive apps, Lift is it.

>    - What other languages will Lift support? Initially, it'll be JRuby...

>    once we get the JRuby APIs nice and clean, we'll look around for the next
>    language to support.  Maybe it'll be mainstream Java (if we can solve API
>    issues like pattern matching in Ruby, maybe a better answer will come along
>    for Java).  Maybe it'll be Clojure.  But whatever the next language on the
>    Lift polyglot tour, it'll feel native to that language (even if that means
>    annotations in Java... gaaakkk).

>    - Will this derail the Lift documentation efforts?  No, just the

>    opposite, as we work through the APIs, I plan to document them much more
>    cleanly.
>
> So, what needs to be done on the Lift side to support JRuby:
>

>    1. Snippets — invoking a Ruby script
>    2. Support for box/option (this may be as simple as making Box implement
>    java.lang.Iterable)
>    3. S, SHtml, LiftRules
>    4. Boot
>    5. SiteMap
>    6. SessionVar/Vars
>    7. Helpers
>    8. CSS Selector Transforms
>    9. Alternative to pattern matching

[TylerWeir]

Increasing the user base can only help the framework mature and harden.

Huzzah!

[Rick]

I think this is great news. I've been thinking along these lines for a
while now and have been fluctuating back and forth between feeling I
need to learn Ruby and Rails but feeling the technically superior pull
of Scala and Lift. I see this as a very practical approach to
providing a way for web developers who are moving away from Java to
Ruby and Rails who will want to adopt Scala and Lift once awareness
has grown. I've been evangelizing for both ROR and Scala and Lift for
some time now and look forward to seeing how this develops. I'm
relatively new to both technologies but hope to be able to participate
as my skills improve.
Thanks David!

Rick

On Jan 11, 11:14 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Blohowiakhttp://twitter.com/#!/aaronblohowiak) to help design the Lift

> Ruby APIs... because they have to be different from the Lift Scala APIs.
> And where Lift uses a lot of Scala's pattern matching, we will work on a
> Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
>

>    - No, Lift is not abandoning Scala... the core parts of Lift will always

>    be written in Scala... it's my favorite language and it's a powerful
>    language for expressing the kind of semantics that have made Lift powerful
>    and different.

>    - Why would someone use Lift with JRuby when they can use Rails?  Lift is

>    hands-down the best web framework available today.  It's got better
>    semantics for Comet and Ajax than any other web framework.  It's more secure
>    by default than most other web frameworks.  Lift-based apps scale nicely.
>    Lift apps are more concise than most other web apps.  Put another way, if
>    you're a Ruby developer looking for a more secure, more scalable web
>    framework that allows you to build more interactive apps, Lift is it.

>    - What other languages will Lift support? Initially, it'll be JRuby...

>    once we get the JRuby APIs nice and clean, we'll look around for the next
>    language to support.  Maybe it'll be mainstream Java (if we can solve API
>    issues like pattern matching in Ruby, maybe a better answer will come along
>    for Java).  Maybe it'll be Clojure.  But whatever the next language on the
>    Lift polyglot tour, it'll feel native to that language (even if that means
>    annotations in Java... gaaakkk).

>    - Will this derail the Lift documentation efforts?  No, just the

>    opposite, as we work through the APIs, I plan to document them much more
>    cleanly.
>
> So, what needs to be done on the Lift side to support JRuby:
>

>    1. Snippets — invoking a Ruby script
>    2. Support for box/option (this may be as simple as making Box implement
>    java.lang.Iterable)

>    3. S, SHtml, LiftRules
>    4. Boot
>    5. SiteMap
>    6. SessionVar/Vars
>    7. Helpers
>    8. CSS Selector Transforms

>    9. Alternative to pattern matching

[Marius Danciu]

I've read this and it's weed that I can't form an opinion on this for myself. I understand that are obviously some good benefits for some "market" out there but I have the feeling that there will be great caveats and compromises into supporting these languages. I think one of the main reasons for Lift's popularity and power is Scala itselft. But this aspect won't diminish whatsoever.

Br's,
Marius

[Esko Luontola]

On Jan 12, 6:14 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> During the
> call, it struck me light a bolt of lightening... it'll be 10+ years before
> the mainstream corporate developers (and they are the ones with money) adopt
> Scala... they're currently swallowing Ruby and having a not-great time of
> it.
>
> I realized Lift had to broaden outside of Scala.

Sounds like you're onto something.

Recently I had similar thoughts about my Scala-based testing framework
(https://github.com/orfjackal/specsy) that it would make sense for it
to be usable from any JVM language. Groovy, JRuby and Clojure support
should be easy because they have closures, but figuring out an equally
expressive syntax for Java was a much harder problem.

Below is an example of what the testing framework currently looks like
in Scala and the most feasible draft of how the same could be
expressed in Java. I think that in Java nested anonymous inner classes
could be used as an alternative to closures (Scala's mutable local
variable in closure vs. Java's field in anonymous inner class).

StackSpec example in Scala:
https://github.com/orfjackal/specsy/blob/41530a8560e2d2285628ed20681c1cf2056b1af0/src/test/scala/net/orfjackal/specsy/examples/StackSpec.scala

StackSpec example in Java:
https://github.com/orfjackal/specsy/blob/41530a8560e2d2285628ed20681c1cf2056b1af0/src/test/java/net/orfjackal/specsy/examples/JavaStackSpecDraft2.java

I wrote about it more at http://groups.google.com/group/specsy/browse_thread/thread/64744ace02d5e66d

[Andy Czerwonka]

Hmnn... I'm not sure how I feel about this one.  I dare to say good and bad.  Good, because making Lift more accessible is great.  The more people the better. Bad for two reasons. Firstly, Ruby is on a steady and sharp popularity decline since 2009 and I don't see that changing anytime soon, while Scala is on the incline, so I really don't see the point. Secondly, effort could be used for much more important aspects of Lift.

Just because you can doesn't mean you should.  Just my 2 cents.

[work only]

Hi

The Java Posse on last podcast said that 2011 is the year of Scala, judging by Java One!

I do see Scala more and more on the web and do believe that Scala will be big in 2011 :)

Paul :)

On Wed, Jan 12, 2011 at 2:13 PM, Andy Czerwonka <andy.cz...@gmail.com> wrote:

Hmnn... I'm not sure how I feel about this one.  I dare to say good and bad.  Good, because making Lift more accessible is great.  The more people the better. Bad for two reasons. Firstly, Ruby is on a steady and sharp popularity decline since 2009 and I don't see that changing anytime soon, while Scala is on the incline, so I really don't see the point. Secondly, effort could be used for much more important aspects of Lift.

Just because you can doesn't mean you should.  Just my 2 cents.

--

[therac25]

I would have thought that most Lift users came to Lift in the first
place, because they wanted to use Scala for web development (I know I
did). At the moment I feel Lift is still far behind Django or Rails in
terms of documentation, tutorials available and general beginner-
friendliness. I also feel that trying to woo Rubyists away from Rails
is a waste of time, you might have more luck with Java though...

Personally, I'd rather see Lift become more accessible, with a
smoother learning curve, a quick way to get started, (without having
to figure out out first what Maven and SBT do, which IDE works well,
which version of Lift and which learning resources to pick...), some
nice tutorial (a small blog app a la Rails... the pocket change app is
close but it's not in quick-tutorial format)

Anyway my 2 cents

Emmanuel



On Jan 12, 5:14 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Blohowiakhttp://twitter.com/#!/aaronblohowiak) to help design the Lift

> Ruby APIs... because they have to be different from the Lift Scala APIs.
> And where Lift uses a lot of Scala's pattern matching, we will work on a
> Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
>

>    - No, Lift is not abandoning Scala... the core parts of Lift will always

>    be written in Scala... it's my favorite language and it's a powerful
>    language for expressing the kind of semantics that have made Lift powerful
>    and different.

>    - Why would someone use Lift with JRuby when they can use Rails?  Lift is

>    hands-down the best web framework available today.  It's got better
>    semantics for Comet and Ajax than any other web framework.  It's more secure
>    by default than most other web frameworks.  Lift-based apps scale nicely.
>    Lift apps are more concise than most other web apps.  Put another way, if
>    you're a Ruby developer looking for a more secure, more scalable web
>    framework that allows you to build more interactive apps, Lift is it.

>    - What other languages will Lift support? Initially, it'll be JRuby...

>    once we get the JRuby APIs nice and clean, we'll look around for the next
>    language to support.  Maybe it'll be mainstream Java (if we can solve API
>    issues like pattern matching in Ruby, maybe a better answer will come along
>    for Java).  Maybe it'll be Clojure.  But whatever the next language on the
>    Lift polyglot tour, it'll feel native to that language (even if that means
>    annotations in Java... gaaakkk).

>    - Will this derail the Lift documentation efforts?  No, just the

>    opposite, as we work through the APIs, I plan to document them much more
>    cleanly.
>
> So, what needs to be done on the Lift side to support JRuby:
>

>    1. Snippets — invoking a Ruby script
>    2. Support for box/option (this may be as simple as making Box implement
>    java.lang.Iterable)

>    3. S, SHtml, LiftRules
>    4. Boot
>    5. SiteMap
>    6. SessionVar/Vars
>    7. Helpers
>    8. CSS Selector Transforms

>    9. Alternative to pattern matching

[Philippe Jean]

2011/1/13 therac25 <th3r...@googlemail.com>

I would have thought that most Lift users came to Lift in the first
place, because they wanted to use Scala for web development (I know I
did).

I think it's the same for everybody.

 

At the moment I feel Lift is still far behind Django or Rails in
terms of documentation, tutorials available and general beginner-
friendliness.

Lift's community does a great job on that and needs to continue.

 

I also feel that trying to woo Rubyists away from Rails
is a waste of time, you might have more luck with Java though...

True, the ruby ecosystem is very large and really loved by Rubyists.

I think will should have the same. Why Sbaz it's not our RubyGems ?

Personally, I'd rather see Lift become more accessible, with a
smoother learning curve, a quick way to get started,

Obtain Lift, Lift's module, Lifty, ...  from Sbaz should be a good approach to start quickly.

 

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

Philippe Jean

[Andy Czerwonka]

I agree.  I'm actually baffled as to why Lift would want to extend its footprint into the Ruby community.  Strategically, it makes little sense.

[work only]

I think Philippe is 100% right!

I'm changing my mind again, I think adding jRuby is wrong.

I came to Lift because of Scala.

Need to make Lift more accessible, I think 2011 will be Scala year, so why spend time on Ruby.

Paul

[Donald McLean]

I have to thoroughly agree with this.

Except that there is not need to use Maven or SBT (Ant still works
just fine, even if it isn't quite so glamorous) and though the IDEA
plugin is still a little rough, it isn't bad.

Donald

[Andy Czerwonka]

As you can see from my post above, I 100% agree.  I think this Ruby experiment is more about "when can, so we will" versus "we should".  Building documentation and tools is not as fun and sexy as solving technical problems - we can all agree to that if we're developers - but the mileage we'd get  in terms of solving the accessibility problem is much higher.

[S?ren Bramer Schmidt]

It is very difficult to determine current and future usage of a language.

First: The indeed job index disagrees http://www.indeed.com/jobtrends?q=%22ruby%22,+%22python%22,+scala&l=

Second: Even if the Tiobe index is a reasonable measure, Ruby is still 10 times as "popular" as Scala http://www.tiobe.com/index.php/paperinfo/tpci/

Exposing Lift to the many talented ruby developers will increase the influx of ideas and feature requests as well as bring on board more people to write tutorials and the likes.

Hopefully David and the rest of the comitters will be able to work with, be inspired by an learn a thing or two from some of the bright people at the ror core team.

Onwards and upwards :-)

[David Pollak]

On Thu, Jan 13, 2011 at 9:07 AM, Donald McLean <dmcl...@gmail.com> wrote:

I have to thoroughly agree with this.

And you can keep using Lift with Scala.  Lift is written in Scala and the Scala APIs will always be excellent.  There's no cost to you or anyone using Scala because there will be other language bindings.

The choice of JRuby is the choice that I made and it's the investment that I'm going to make.  If someone else wants to make the investment in other language bindings (design, implementation, support), I welcome the discussion, but saying "that's a bad decision" without stepping up with an alternative doesn't help anyone.
 

Lift is not in the IDE business nor is it in the build tool business.  All you need to get started with Lift is Java, zip or tar and a text editor.  The learning curve for sbt is "sbt clean", "sbt update", "sbt jetty-run", "sbt jetty-stop" and "sbt package"  That's it.  Complaining that it's hard is not valuable or even credible.

We've got a number of tutorials (Pocket Change, To do, Lift's getting started and chapters 2-4 of Simply Lift).
 

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@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
Blog: http://goodstuff.im
Surf the harmonics

[Derek Chen-Becker]

Also, it appears the David will be working with the JRuby team (Charles) to add/strengthen functionality in JRuby to make using Lift from JRuby as clean as possible. I think that the maintenance of any JRuby-specific code in Lift is going to be minimal because for the most part a lot of things are common (the whole JVM thing).

Derek

On Thu, Jan 13, 2011 at 11:09 AM, Maarten Koopmans <maarten....@gmail.com> wrote:

On Thu, Jan 13, 2011 at 6:26 PM, David Pollak <feeder.of...@gmail.com> wrote:

On Thu, Jan 13, 2011 at 9:07 AM, Donald McLean <dmcl...@gmail.com> wrote:

I have to thoroughly agree with this.

And you can keep using Lift with Scala.  Lift is written in Scala and the Scala APIs will always be excellent.  There's no cost to you or anyone using Scala because there will be other language bindings.

The choice of JRuby is the choice that I made and it's the investment that I'm going to make.  If someone else wants to make the investment in other language bindings (design, implementation, support), I welcome the discussion, but saying "that's a bad decision" without stepping up with an alternative doesn't help anyone.

I think the fear of people here is that it will slow Lift's core development down, because language bindings take energy to build and maintain. By itself that's a viable alternative (opinion) that I don't share. The way I see it, Lift is pretty feature-complete with the HTML5 support and CSS selectors - the rest is maturing. Which includes language bindings.

What would scare me is if David and the core team would say that they would put Lift on hold for a rewrite in [.....] But that's not the case at all! This is an excellent opportunity to broaden and strengthen the community.

As for documentation - it's pretty good, especially when you use Lift in Action, the WIki, Simply Lift and Exploring Lift side by side. With that and the speedy replies on this list, I haven't had much problems.

--Maarten

[Donald McLean]

The books are pretty good, admittedly.

The ScalaDoc, I have found, is rife with missing information that has
consistently rendered it nearly useless (at least to me anyway).

Donald

[Derek Chen-Becker]

I know it's little consolation, but every time I touch the code I try to work on ScalaDocs as well.

--

[Andy Czerwonka]

It's subjective to be sure.  The 10-times comes from Ruby having a killer app, Rails.  I'd like to see how many non-Rails Ruby developers there are.  I'm guessing just a little more than zero.  Lift could be that for Scala, but not if we're do muddy the water.

I'm not convinced that if we're to venture into supporting an alternative language Ruby is it.