Will scala be the next Java? Is it too hard for the majority of coders?

On Saturday July 18 2009, Ken Egervari wrote:
> Hi everyone,
>
> I'm just getting into Scala, and I'm really enjoying it. It's a very
> cool language, and I'm so happy it exists. Thanks!
>
> I'm curious... what are the chances that Scala will get adopted with
> the same popularity as C, C++ or Java?

I have yet to grasp the importance of popularity of a language...

> Also, do you think Scala is a tad too hard?

No. Not if you're willing to think about what you do and change.

If you want to call yourself a software engineer, you should be quite
dissatisfied with Java and C and Ruby and Python and Perl and Groovy,
just to hit the high spots.

The way we do software has to change. Our tools and techniques for
designing and writing software are barely keeping ahead of the curve of
hardware capability, user demand and our own ambitions. If we fall
behind that curve, software reliability, already pretty poor, will
slide even further.

Anyway, Scala is not really hard to use. There's more to learn, but it
shifts the balance of impediment and effort at least somewhat in such a
way that makes it's easier to write less bad code than with those other
languages. And if make it a criterion to write more sound code, it
affords much more in the way of language features that cater to that
requirement than today's mainstream languages.

> I find that tons of developers still are ...
>
> What do you think?

I think Sturgeon was an optimist.

> Ken

Randall Schulz

Hi Randal,

I most certainly agree that Scala is a big step up from the current languages. That is precisely what had me investigate it.

Still, popularity is important for many reasons. It's good to know that the industry is behind a language rather than just a few rogue companies and programmers. It's also good to know that libraries, tool support, etc. would be developed at a much more rapid pace. And I think it would be nice to know 1 other developer in my city using Scala (unlikely).

I do feel that Java itself has gotten way too bloated. And the support community for Spring and Hibernate is really slowing down - it's no where near where it was in 2003-2005. I think people have generally moved on. It's weird how these technologies are so ubiquitous, and yet, the forums are ghost towns.

I also don't find it hard personally. I feel that there's definitely a lot more to it. I think a "Scala Master" would have to know a great deal more than a "Java Master", as far as language features, best practices, etc. are concerned.

Knowing what i know about the average developer, they are already "not thinking", so I don't really trust them to use their head using Scala any more than they already use it for Java or C# or any other language. I guess that is what I'm worried about ;)

Ken

On Sat, Jul 18, 2009 at 10:14 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Saturday July 18 2009, Ken Egervari wrote:
> Hi everyone,
>
> I'm just getting into Scala, and I'm really enjoying it. It's a very
> cool language, and I'm so happy it exists. Thanks!
>
> I'm curious... what are the chances that Scala will get adopted with
> the same popularity as C, C++ or Java?

I have yet to grasp the importance of popularity of a language...


> Also, do you think Scala is a tad too hard?

No. Not if you're willing to think about what you do and change.

If you want to call yourself a software engineer, you should be quite
dissatisfied with Java and C and Ruby and Python and Perl and Groovy,
just to hit the high spots.

The way we do software has to change. Our tools and techniques for
designing and writing software are barely keeping ahead of the curve of
hardware capability, user demand and our own ambitions. If we fall
behind that curve, software reliability, already pretty poor, will
slide even further.

Anyway, Scala is not really hard to use. There's more to learn, but it
shifts the balance of impediment and effort at least somewhat in such a
way that makes it's easier to write less bad code than with those other
languages. And if make it a criterion to write more sound code, it
affords much more in the way of language features that cater to that
requirement than today's mainstream languages.


> I find that tons of developers still are ...
>
> What do you think?

I think Sturgeon was an optimist.


> Ken


Randall Schulz

On Sun, Jul 19, 2009 at 12:14 PM, Randall R Schulz wrote:
> I have yet to grasp the importance of popularity of a language...

I sincerely hope you're just saying this for rhetorical effect.

Stuart

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

Alexy Khrabrov wrote:
> Scala has no serious DB access approach, or numerics, showing it
> heavily relies on Java ways, backward ones. .Net is far ahead with
> LINQ for real-life jobs, it has strong numerics, advanced parallelism,
> etc. Scala actors must become much more robust before competing well
> with F#. Generally, a single library must win inside Scala for
> actors, for IO, etc., to simplify it. Same with the build system.
>

Scala has (far far) more advanced parallelism than .NET Parallel. It's
just not in the core library. There are features that .NET/F# does not
have which means it will never have that level of parallelism.

The build system problem will be solved soon I hope
http://hackage.haskell.org/package/Lastik

Are there any efforts to introduce LINQ (SQL) like syntax for querying in Scala?  I saddens me that this isn't available directly in the language.

2009/7/19 Alexy Khrabrov <deliverable@gmail.com>

Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.

On Sun, Jul 19, 2009 at 10:41 AM, Mohamed Bana <mbana.lists@googlemail.com>wrote:

Are there any efforts to introduce LINQ (SQL) like syntax for querying in Scala?  I saddens me that this isn't available directly in the language.

There's scala-query (and on GitHub), which is very promising.  It mentions certain features of LINQ -- using expressions ASTs directly -- which make it easier than Scala, but perhaps that can be rectified in the future?
Cheers,Alexy

On Sunday July 19 2009, Mohamed Bana wrote:
> Are there any efforts to introduce LINQ (SQL) like syntax for
> querying in Scala? I saddens me that this isn't available directly
> in the language.

As you no doubt know, Scala is specifically designed to keep such
specifics out of the language by enabling their creation using generic
constructs.

What is the gap between Scala's for comprehensions and LINQ?

Randall Schulz

Tony Morris wrote:
> Scala has (far far) more advanced parallelism than .NET Parallel. It's
> just not in the core library. There are features that .NET/F# does not
> have which means it will never have that level of parallelism.

I would actually argue that (as of now), neither Scala nor .NET has what
one can reasonably call advanced parallelism. When it comes to
concurrency, both have tools that basically get the job done, but both
also leave many important questions unanswered and require software
designers to create their own solutions to important problems, often
with inadequate tools.

The same is true of any other language, of course, and not really the
fault of the language designers. The problem is two-fold: For one thing,
in the realm of concurrency, there really is no "one size fits all"
approach. The toolset you would need to address all possible problems,
just picking from currently available techniques to cover all
eventualities, is really, really big. The other problem is that most
advanced techniques for concurrency management (especially ones that
address both software engineering issues AND performance) are still on
the bleeding edge of research in labs worldwide; meaning that they are
still very much under development and are often unproven in real-world
applications.

Reimer Behrends

Alexy Khrabrov wrote:

> There's scala-query
> (and
> on GitHub
> ), which is very promising. It mentions certain features of LINQ -- using expressions ASTs directly

On Sunday July 19 2009, Reimer Behrends wrote:
> Tony Morris wrote:
> > Scala has (far far) more advanced parallelism than .NET Parallel.
> > ...
>
> I would actually argue that (as of now), neither Scala nor .NET has
> what one can reasonably call advanced parallelism. ...
>
> The same is true of any other language, of course, and not really the
> fault of the language designers. ...
>
> Reimer Behrends

As someone with fairly little knowledge of this realm (but who, like
most of us, needs to know more), I wonder what you think of STM as an
ingredient in parallel processing designs. Are you familiar with
Clojure's incorporation of STM into the language itself and if so what
do you think of it?

Randall Schulz

Randall Schulz wrote:
>
> What is the gap between Scala's for comprehensions and LINQ?
>

Basically it's that LINQ will automagically translate C# expressions into
SQL, so that queries like

for(x<-MySQLTable if x.id = "foo"){

}

translate into an index lookup rather than a full-table scan followed by
testing in memory. The closest you could get in Scala would be creating a
DSL for queries, which is less convenient. That's what requires LINQ be
able to introspect the C# AST.

--Dave

i think i should have bought this to light also;

  http://wcook.blogspot.com/2008/10/linq-is-best-option-for-future-java.html 

by Prof. William R. Cook

2009/7/19 Mohamed Bana <mbana.lists@googlemail.com>

Are there any efforts to introduce LINQ (SQL) like syntax for querying in Scala?  I saddens me that this isn't available directly in the language.

2009/7/19 Alexy Khrabrov <deliverable@gmail.com>

Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.

On Sun, Jul 19, 2009 at 5:59 PM, Dave
Griffith wrote:
> translate into an index lookup rather than a full-table scan followed by
> testing in memory.    The closest you could get in Scala would be creating a
> DSL for queries, which is less convenient.    That's what requires LINQ be
> able to introspect the C# AST.
Actually this is possible even right now. There is the undocumented
scala.reflect.Code feature which lets you access the AST of code. This
feature, though, is not in the best shape. It works quite good for
simple closures, for simple expressions, though, it fails with
compiler exceptions the last time I checked.

Randall R Schulz wrote:
> As someone with fairly little knowledge of this realm (but who, like
> most of us, needs to know more), I wonder what you think of STM as an
> ingredient in parallel processing designs. Are you familiar with
> Clojure's incorporation of STM into the language itself and if so what
> do you think of it?

I am not familiar with Clojure's implementation in particular (though I
know the language side of things), but I believe I'm generally fairly
up-to-date on the current state of the art with respect to STM research,
so I can mention a few general points.

There are two principal benefits that you can gain from using STM. One
is that being able to say that a code is to be treated as an
indivisible, atomic operation is a powerful abstraction mechanism (you
don't have to explicitly juggle locks and such). The other benefit is
that STM is generally very good at exploiting fine-grained parallelism
(the often-cited example is performance on red-black trees).

STM currently suffers from a number of limitations, unfortunately. One
of those limitations is that performance isn't very good right now (see
http://portal.acm.org/citation.cfm?id=1454456.1454466 for a critical
view of this). Because you have to instrument every read or write
operation to shared memory with either a hash table lookup or a lock
operation or something similarly expensive, the transactional code will
generally take several times as long to complete as the purely
sequential equivalent, even in the absence of contention. That includes
state-of-the-art implementations.

It's not impossible to write implementations that don't have that
overhead (as a simple example, using a single global lock gives you
transactional semantics), but then you generally sacrifice parallelism
for the reduced overhead. As an intermediate example, I have recently
implemented a prototype of an algorithm that does pretty well in terms
of overhead for a low number of threads compared to other
implementations, but parallelism at 32+ threads begins to deteriorate,
and it also still needs help from user annotations to get to such a low
level of overhead.

Second, even not considering the overhead, some types of applications
are hard to parallelize using STM. Consider operations on splay trees or
scapegoat trees, for example. Every insert and delete operation in those
types of trees gets serialized on the root or the metadata,
respectively, because every operation needs to modify those. Another
simple example is having a hash table with a size field. Operations on
the hash table as such are easy to parallelize (even without STM), but
modifying the size field is a serialization bottleneck. Workarounds
generally need open nested transactions (a type of nesting where a child
transaction can commit before the parent does), and open nesting has
very subtle semantics that are easy to get wrong by non-experts.

Third, STM has problems expressing irreversible operations. Any
operation that cannot be reversed can generally not occur inside an STM
transaction. That makes it difficult to use operations that access the
OS, spawn new threads, or even access external libraries inside a
transaction. While there are possible solutions, they are not without
drawbacks. For example, the code generated by Intel's compiler uses one
of two exclusive modes when it discovers code which it cannot properly
transactionalize, but that effectively serializes such transactions. Or
you can rely on user annotations to address these issues (see
http://portal.acm.org/citation.cfm?id=1297105.1297042 for example;
disclaimer: I co-authored the paper).

Personally, I see a number of promising applications for STM, but I do
not consider it (yet) to be a one-size-fits all solution. An example of
something that could be interesting would be using STM in conjunction
with an actor-based model to gain reliable intra-actor concurrency, once
you've got the semantics of that worked out, or to have safe and
efficient concurrent access to shared data structures when all actors
are actually hosted on the same machine (similar in effect to using
Erlang's Mnesia in in-memory mode) once the performance issues have been
ironed out.

Reimer Behrends

Sure, see for-comprehensions.

2009/7/19 Mohamed Bana :
> Are there any efforts to introduce LINQ (SQL) like syntax for querying in
> Scala?  I saddens me that this isn't available directly in the language.
>
> 2009/7/19 Alexy Khrabrov
>>
>> Scala has no serious DB access approach, or numerics, showing it heavily
>> relies on Java ways, backward ones.  .Net is far ahead with LINQ for
>> real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala
>> actors must become much more robust before competing well with F#.
>>  Generally, a single library must win inside Scala for actors, for IO, etc.,
>> to simplify it.  Same with the build system.
>
>

Dave Griffith wrote:
> Basically it's that LINQ will automagically translate C# expressions into
> SQL, so that queries like
>
> for(x<-MySQLTable if x.id = "foo"){
>
> }
>
> translate into an index lookup rather than a full-table scan followed by

With ScalaQuery:

object MySQLTable extends Table[(String, Int)]("MySQLTable") {
def id = column[String]("id")
def value = column[Int]("value")
def * = id ~ name
}

val q = for(x <- MySQLTable where {_.id is "foo" }) yield x.value

println("Value for foo: " + q.first)

> testing in memory. The closest you could get in Scala would be creating a
> DSL for queries, which is less convenient. That's what requires LINQ be

Yes, that's what ScalaQuery does.

On Sun, Jul 19, 2009 at 7:29 PM, Stefan Zeiger wrote:
>    val q = for(x <- MySQLTable where {_.id is "foo" }) yield x.value

Now does it support more complex queries than that?

F.ex.

with salesData as (
select
product,
sum(1) over (partition by product order by date) as day,
qty
from sales
where date >= ?
)
select product, day, sum(qty) over (partition by product, day order by
day) as accQty
from salesData sd
where exists (select 1 from stock s where s.product = sd.product)

BR,
John

John Nilsson wrote:
>
>
> Now does it support more complex queries than that?
>

I'm not an expert on the LINQ implementation, but reading the docs the
answer would appear to be yes. Certainly joins, grouping, and aggregation
are supported. The syntax gets a bit DSL-ish, but appears to support raw C#
queries pretty much every place you would want, and looks to compile to the
SQL you would hope for.

--Dave

John Nilsson wrote:
> Now does it support more complex queries than that?
>
> F.ex.

Not yet, but it should fit well into the current framework.

> with salesData as (

Okay, a materialized subquery. Could be an done as an option on queries
or subquery lifting so that the SQL generator can rewrite it.

> select
> product,
> sum(1) over (partition by product order by date) as day,

SUM OVER is shorthand for an inner join (which is implemented). Ordering
is in, aggregation and partitioning not yet (but should be doable in the
same way).

> qty
> from sales
> where date >= ?

No relational operators yet but they are trivial to add. Bind variables
are supported since two hours ago :)

> )
> select product, day, sum(qty) over (partition by product, day order by
> day) as accQty
> from salesData sd
> where exists (select 1 from stock s where s.product = sd.product)

No EXISTS yet but this should also be trivial.

Just to be clear, there are two common misconceptions that C#
programmers have about LINQ:

1. It has something to do with SQL.

Linq2Sql exists, and LINQ syntax borrows from SQL, but just like for
comprehensions in Scala, and do-notation in Haskell, you can use LINQ
for anything. I used it for a QuickCheck prototype, for example.

2. It has something to do with IEnumerable<>.

When one types 'using System.Linq;', LINQ syntax can be used over
collections. It's very good, with the slight complaint that it's
overly lazy, so one ends up adding .ToList() to improve performance.
But LINQ is not at all dependent on System.Linq.

2009/7/19 Dave Griffith :
>
>
>
> John Nilsson wrote:
>>
>>
>> Now does it support more complex queries than that?
>>
>
> I'm not an expert on the LINQ implementation, but reading the docs the
> answer would appear to be yes.   Certainly joins, grouping, and aggregation
> are supported.  The syntax gets a bit DSL-ish, but appears to support raw C#
> queries pretty much every place you would want, and looks to compile to the
> SQL you would hope for.
>
> --Dave
>
> --
> View this message in context: http://www.nabble.com/-scala--Will-scala-be-the-next-Java--Is-it-too-har...
> Sent from the Scala mailing list archive at Nabble.com.
>
>

Reimer Behrends wrote:
> Tony Morris wrote:
>> Scala has (far far) more advanced parallelism than .NET Parallel. It's
>> just not in the core library. There are features that .NET/F# does not
>> have which means it will never have that level of parallelism.
>
> I would actually argue that (as of now), neither Scala nor .NET has
> what one can reasonably call advanced parallelism. When it comes to
> concurrency, both have tools that basically get the job done, but both
> also leave many important questions unanswered and require software
> designers to create their own solutions to important problems, often
> with inadequate tools.
>
> The same is true of any other language, of course, and not really the
> fault of the language designers. The problem is two-fold: For one
> thing, in the realm of concurrency, there really is no "one size fits
> all" approach. The toolset you would need to address all possible
> problems, just picking from currently available techniques to cover
> all eventualities, is really, really big. The other problem is that
> most advanced techniques for concurrency management (especially ones
> that address both software engineering issues AND performance) are
> still on the bleeding edge of research in labs worldwide; meaning that
> they are still very much under development and are often unproven in
> real-world applications.
>
> Reimer Behrends
>
>
I didn't call it advanced. I called it far far more advanced than .NET
Parallel. I agree otherwise.

I still have to dive into Lift. My first goal is to really learn the language. I'm going through the Programming in Scala book, and it's probably one of the best programming books I've ever read. I haven't read a "how to program in this language" book in a long time though. I just like the writing style, the brevity, and the good explanations. The book seems to be answer every question in my mind, and is one step ahead of me. It doesn't just give you some code and take things from granted. I really like that.

I hope the Lift framework is solid. The Java world is so bloated these days. Programming in raw Spring is actually more of a headache than it was in 2003-2005. More things can go wrong than ever. The worst thing about it is tracking bugs in the frameworks or just figuring out what it's doing can be a monstrous pain in the rear. We're talking about hours of digging to find problems. This is not fun nor productive.

Spring Roo seems to be the answer the above problems - unifying best practices, configuration and getting rid of as much bloat as possible. Lots of the above mention problems are a result of the developer having to configure things incorrect, or having to discover best practices and the right way to do things on their own.

Grails has a good approach - unifying everything and getting rid of a lot of the bloat. Still, it's a bit behind technology-wise, and it's pretty slow performance-wise until Groovy manages to speed up. It's still better than RoR though.

Still, if Scala had a solution that was not so bloated, and achieved much of the same benefits... plus the benefits that Scala brings... that would be a real winner.

What is currently missing from the Scala stack? I'd actually like to work on a open-source project in Scala.

Ken

On Sat, Jul 18, 2009 at 11:04 PM, Alexy Khrabrov <deliverable@gmail.com> wrote:

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

The glaring hole in scala is IDE support.  Thankfully, Miles Sabin already has that well under hand with the upcoming 2.8 eclipse plugin.
A lot of familiar tools such as debuggers and code coverage test reporting should already work, as the line number debugging symbols emitted by the scala compiler are 100% compatible with java source.
A lot more "pimping" of various popular libraries to better support Scala idioms would also be a big boost.  I would strongly recommend such a project if you already don't have an idea of your own and are just looking to roll up your sleeves and dive into the language..


On Sun, Jul 19, 2009 at 11:16 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I still have to dive into Lift. My first goal is to really learn the language. I'm going through the Programming in Scala book, and it's probably one of the best programming books I've ever read. I haven't read a "how to program in this language" book in a long time though. I just like the writing style, the brevity, and the good explanations. The book seems to be answer every question in my mind, and is one step ahead of me. It doesn't just give you some code and take things from granted. I really like that.

I hope the Lift framework is solid. The Java world is so bloated these days. Programming in raw Spring is actually more of a headache than it was in 2003-2005. More things can go wrong than ever. The worst thing about it is tracking bugs in the frameworks or just figuring out what it's doing can be a monstrous pain in the rear. We're talking about hours of digging to find problems. This is not fun nor productive.

Spring Roo seems to be the answer the above problems - unifying best practices, configuration and getting rid of as much bloat as possible. Lots of the above mention problems are a result of the developer having to configure things incorrect, or having to discover best practices and the right way to do things on their own.

Grails has a good approach - unifying everything and getting rid of a lot of the bloat. Still, it's a bit behind technology-wise, and it's pretty slow performance-wise until Groovy manages to speed up. It's still better than RoR though.

Still, if Scala had a solution that was not so bloated, and achieved much of the same benefits... plus the benefits that Scala brings... that would be a real winner.

What is currently missing from the Scala stack? I'd actually like to work on a open-source project in Scala.

Ken

On Sat, Jul 18, 2009 at 11:04 PM, Alexy Khrabrov <deliverable@gmail.com> wrote:

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

Yeah Kevin, I would love any suggestions of things that need to be created. I honestly learn best by having a goal - something to work on - especially if it'll be something I know I will personally use myself. I used to write all kinds of frameworks in Java back in 2000-2004. Most of my stuff was private, and many of the things I worked on were implemented in Spring and Hibernate. I'd love to do stuff like that in Scala.

Right now, I don't have any projects in mind. I just want to learn and get really good with Scala, and just get my brain thinking the new paradigm... learning new best practices... and all that good stuff. What are some of your ideas?

Ken

On Sun, Jul 19, 2009 at 6:29 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

The glaring hole in scala is IDE support.  Thankfully, Miles Sabin already has that well under hand with the upcoming 2.8 eclipse plugin.
A lot of familiar tools such as debuggers and code coverage test reporting should already work, as the line number debugging symbols emitted by the scala compiler are 100% compatible with java source.
A lot more "pimping" of various popular libraries to better support Scala idioms would also be a big boost.  I would strongly recommend such a project if you already don't have an idea of your own and are just looking to roll up your sleeves and dive into the language..


On Sun, Jul 19, 2009 at 11:16 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I still have to dive into Lift. My first goal is to really learn the language. I'm going through the Programming in Scala book, and it's probably one of the best programming books I've ever read. I haven't read a "how to program in this language" book in a long time though. I just like the writing style, the brevity, and the good explanations. The book seems to be answer every question in my mind, and is one step ahead of me. It doesn't just give you some code and take things from granted. I really like that.

I hope the Lift framework is solid. The Java world is so bloated these days. Programming in raw Spring is actually more of a headache than it was in 2003-2005. More things can go wrong than ever. The worst thing about it is tracking bugs in the frameworks or just figuring out what it's doing can be a monstrous pain in the rear. We're talking about hours of digging to find problems. This is not fun nor productive.

Spring Roo seems to be the answer the above problems - unifying best practices, configuration and getting rid of as much bloat as possible. Lots of the above mention problems are a result of the developer having to configure things incorrect, or having to discover best practices and the right way to do things on their own.

Grails has a good approach - unifying everything and getting rid of a lot of the bloat. Still, it's a bit behind technology-wise, and it's pretty slow performance-wise until Groovy manages to speed up. It's still better than RoR though.

Still, if Scala had a solution that was not so bloated, and achieved much of the same benefits... plus the benefits that Scala brings... that would be a real winner.

What is currently missing from the Scala stack? I'd actually like to work on a open-source project in Scala.

Ken

On Sat, Jul 18, 2009 at 11:04 PM, Alexy Khrabrov <deliverable@gmail.com> wrote:

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

Tough call...
I guess your best bet is to pick something that personally interests you, then ask on the boards if there are any open source projects in the same area.Either that, or pick a favourite java library and try to pimp it.  I believe this has already been done for jpa, swing and joda-time, amongst others.

On Sun, Jul 19, 2009 at 11:37 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

Yeah Kevin, I would love any suggestions of things that need to be created. I honestly learn best by having a goal - something to work on - especially if it'll be something I know I will personally use myself. I used to write all kinds of frameworks in Java back in 2000-2004. Most of my stuff was private, and many of the things I worked on were implemented in Spring and Hibernate. I'd love to do stuff like that in Scala.

Right now, I don't have any projects in mind. I just want to learn and get really good with Scala, and just get my brain thinking the new paradigm... learning new best practices... and all that good stuff. What are some of your ideas?

Ken

On Sun, Jul 19, 2009 at 6:29 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

The glaring hole in scala is IDE support.  Thankfully, Miles Sabin already has that well under hand with the upcoming 2.8 eclipse plugin.
A lot of familiar tools such as debuggers and code coverage test reporting should already work, as the line number debugging symbols emitted by the scala compiler are 100% compatible with java source.
A lot more "pimping" of various popular libraries to better support Scala idioms would also be a big boost.  I would strongly recommend such a project if you already don't have an idea of your own and are just looking to roll up your sleeves and dive into the language..


On Sun, Jul 19, 2009 at 11:16 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I still have to dive into Lift. My first goal is to really learn the language. I'm going through the Programming in Scala book, and it's probably one of the best programming books I've ever read. I haven't read a "how to program in this language" book in a long time though. I just like the writing style, the brevity, and the good explanations. The book seems to be answer every question in my mind, and is one step ahead of me. It doesn't just give you some code and take things from granted. I really like that.

I hope the Lift framework is solid. The Java world is so bloated these days. Programming in raw Spring is actually more of a headache than it was in 2003-2005. More things can go wrong than ever. The worst thing about it is tracking bugs in the frameworks or just figuring out what it's doing can be a monstrous pain in the rear. We're talking about hours of digging to find problems. This is not fun nor productive.

Spring Roo seems to be the answer the above problems - unifying best practices, configuration and getting rid of as much bloat as possible. Lots of the above mention problems are a result of the developer having to configure things incorrect, or having to discover best practices and the right way to do things on their own.

Grails has a good approach - unifying everything and getting rid of a lot of the bloat. Still, it's a bit behind technology-wise, and it's pretty slow performance-wise until Groovy manages to speed up. It's still better than RoR though.

Still, if Scala had a solution that was not so bloated, and achieved much of the same benefits... plus the benefits that Scala brings... that would be a real winner.

What is currently missing from the Scala stack? I'd actually like to work on a open-source project in Scala.

Ken

On Sat, Jul 18, 2009 at 11:04 PM, Alexy Khrabrov <deliverable@gmail.com> wrote:

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

My interest really likes in enterprise web development, so anything that deals with databases, layering, etc. interests me. Lift itself interests me... so I want to invest some time to learn what that is all about, what it does, what could be added to it, etc.

As far as Java is concerned, I think I'm a very competent framework designer. That's pretty much been my role for a long time, as well as lead architect for big enterprise projects, although I must confess, I like framework design/development a lot better.

Besides Lift itself, anything smaller need to be done? I'd love to work on a small project I could do by myself.

Ken

On Sun, Jul 19, 2009 at 6:59 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Tough call...
I guess your best bet is to pick something that personally interests you, then ask on the boards if there are any open source projects in the same area. Either that, or pick a favourite java library and try to pimp it.  I believe this has already been done for jpa, swing and joda-time, amongst others.

On Sun, Jul 19, 2009 at 11:37 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

Yeah Kevin, I would love any suggestions of things that need to be created. I honestly learn best by having a goal - something to work on - especially if it'll be something I know I will personally use myself. I used to write all kinds of frameworks in Java back in 2000-2004. Most of my stuff was private, and many of the things I worked on were implemented in Spring and Hibernate. I'd love to do stuff like that in Scala.

Right now, I don't have any projects in mind. I just want to learn and get really good with Scala, and just get my brain thinking the new paradigm... learning new best practices... and all that good stuff. What are some of your ideas?

Ken

On Sun, Jul 19, 2009 at 6:29 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

The glaring hole in scala is IDE support.  Thankfully, Miles Sabin already has that well under hand with the upcoming 2.8 eclipse plugin.
A lot of familiar tools such as debuggers and code coverage test reporting should already work, as the line number debugging symbols emitted by the scala compiler are 100% compatible with java source.
A lot more "pimping" of various popular libraries to better support Scala idioms would also be a big boost.  I would strongly recommend such a project if you already don't have an idea of your own and are just looking to roll up your sleeves and dive into the language..


On Sun, Jul 19, 2009 at 11:16 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I still have to dive into Lift. My first goal is to really learn the language. I'm going through the Programming in Scala book, and it's probably one of the best programming books I've ever read. I haven't read a "how to program in this language" book in a long time though. I just like the writing style, the brevity, and the good explanations. The book seems to be answer every question in my mind, and is one step ahead of me. It doesn't just give you some code and take things from granted. I really like that.

I hope the Lift framework is solid. The Java world is so bloated these days. Programming in raw Spring is actually more of a headache than it was in 2003-2005. More things can go wrong than ever. The worst thing about it is tracking bugs in the frameworks or just figuring out what it's doing can be a monstrous pain in the rear. We're talking about hours of digging to find problems. This is not fun nor productive.

Spring Roo seems to be the answer the above problems - unifying best practices, configuration and getting rid of as much bloat as possible. Lots of the above mention problems are a result of the developer having to configure things incorrect, or having to discover best practices and the right way to do things on their own.

Grails has a good approach - unifying everything and getting rid of a lot of the bloat. Still, it's a bit behind technology-wise, and it's pretty slow performance-wise until Groovy manages to speed up. It's still better than RoR though.

Still, if Scala had a solution that was not so bloated, and achieved much of the same benefits... plus the benefits that Scala brings... that would be a real winner.

What is currently missing from the Scala stack? I'd actually like to work on a open-source project in Scala.

Ken

On Sat, Jul 18, 2009 at 11:04 PM, Alexy Khrabrov <deliverable@gmail.com> wrote:

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

Take a look at apache esme for something a bit bigger that uses lift...Lift also has a google group that regularly raises interesting challenges

On Mon, Jul 20, 2009 at 12:09 AM, Ken Egervari <ken.egervari@gmail.com> wrote:

My interest really likes in enterprise web development, so anything that deals with databases, layering, etc. interests me. Lift itself interests me... so I want to invest some time to learn what that is all about, what it does, what could be added to it, etc.

As far as Java is concerned, I think I'm a very competent framework designer. That's pretty much been my role for a long time, as well as lead architect for big enterprise projects, although I must confess, I like framework design/development a lot better.

Besides Lift itself, anything smaller need to be done? I'd love to work on a small project I could do by myself.

Ken

On Sun, Jul 19, 2009 at 6:59 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Tough call...
I guess your best bet is to pick something that personally interests you, then ask on the boards if there are any open source projects in the same area. Either that, or pick a favourite java library and try to pimp it.  I believe this has already been done for jpa, swing and joda-time, amongst others.

On Sun, Jul 19, 2009 at 11:37 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

Yeah Kevin, I would love any suggestions of things that need to be created. I honestly learn best by having a goal - something to work on - especially if it'll be something I know I will personally use myself. I used to write all kinds of frameworks in Java back in 2000-2004. Most of my stuff was private, and many of the things I worked on were implemented in Spring and Hibernate. I'd love to do stuff like that in Scala.

Right now, I don't have any projects in mind. I just want to learn and get really good with Scala, and just get my brain thinking the new paradigm... learning new best practices... and all that good stuff. What are some of your ideas?

Ken

On Sun, Jul 19, 2009 at 6:29 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

The glaring hole in scala is IDE support.  Thankfully, Miles Sabin already has that well under hand with the upcoming 2.8 eclipse plugin.
A lot of familiar tools such as debuggers and code coverage test reporting should already work, as the line number debugging symbols emitted by the scala compiler are 100% compatible with java source.
A lot more "pimping" of various popular libraries to better support Scala idioms would also be a big boost.  I would strongly recommend such a project if you already don't have an idea of your own and are just looking to roll up your sleeves and dive into the language..


On Sun, Jul 19, 2009 at 11:16 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I still have to dive into Lift. My first goal is to really learn the language. I'm going through the Programming in Scala book, and it's probably one of the best programming books I've ever read. I haven't read a "how to program in this language" book in a long time though. I just like the writing style, the brevity, and the good explanations. The book seems to be answer every question in my mind, and is one step ahead of me. It doesn't just give you some code and take things from granted. I really like that.

I hope the Lift framework is solid. The Java world is so bloated these days. Programming in raw Spring is actually more of a headache than it was in 2003-2005. More things can go wrong than ever. The worst thing about it is tracking bugs in the frameworks or just figuring out what it's doing can be a monstrous pain in the rear. We're talking about hours of digging to find problems. This is not fun nor productive.

Spring Roo seems to be the answer the above problems - unifying best practices, configuration and getting rid of as much bloat as possible. Lots of the above mention problems are a result of the developer having to configure things incorrect, or having to discover best practices and the right way to do things on their own.

Grails has a good approach - unifying everything and getting rid of a lot of the bloat. Still, it's a bit behind technology-wise, and it's pretty slow performance-wise until Groovy manages to speed up. It's still better than RoR though.

Still, if Scala had a solution that was not so bloated, and achieved much of the same benefits... plus the benefits that Scala brings... that would be a real winner.

What is currently missing from the Scala stack? I'd actually like to work on a open-source project in Scala.

Ken

On Sat, Jul 18, 2009 at 11:04 PM, Alexy Khrabrov <deliverable@gmail.com> wrote:

I believe that Scala is in a unique position to hit it big among the FP languages, on par only with F#.  Piggy-backing on Java means the world of a difference -- just as basing on .Net is F#'s strength.
Main FP languages such as Haskell and OCaml have devoted mid-size communities, but they're not powering your banking sessions and online commerce -- those URLs usually end with .jsp or .aspx.  Being an open-source guy, I've settled on Scala along with and having been using OCaml, since many useful projects exist in Java.
The key areas which determine popularity of a language, IMHO, are
-- new paradignm: check.  FP + OO.  Nobody does OO along with FP well, and Scala does.-- libraries -- Java interop, check. -- IDE: IDEA, check.-- easy startup -- no check; Maven/Ant/SBT are not there yet and it's not easy to start using all the Java goods.
In terms of language features, one can 'implicit' things to death and much of strict type-checking may be ruined by omitting type annotations and then getting screwed by implicits or unclear overloading.  The compiler must have a hierarchical warning system to avoid dilution of typing, but it helps to bring the Ruby folk aboard.
On the web stage, Ruby folk get a long of things done, but their redundant BDD testing proves what David Pollak noted as a reason to start Lift.  Still the Lift uptake will determine the course of the war, so to speak.
Scala has no serious DB access approach, or numerics, showing it heavily relies on Java ways, backward ones.  .Net is far ahead with LINQ for real-life jobs, it has strong numerics, advanced parallelism, etc.  Scala actors must become much more robust before competing well with F#.  Generally, a single library must win inside Scala for actors, for IO, etc., to simplify it.  Same with the build system.
Scala is really easy to learn if you're not debauched by imperative programming first.  Many courses nowadays are taught with FP, e.g. ML in CS 101 at UPenn or Haskell in CS 101 at Dartmouth, along with Java -- and both ML and Java stayed around for 10 years!  The battle continues between F# and Scala along many of those lines, but ML never achieved the same community momentum as Java.
Overall, the stars are aligned well (on the 64-bit boundaries) to make it happen for Scala.Cheers,Alexy

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499