I am in the process of experimenting with Scala on a small project. I have programmed extensively in Java and Ruby.
I'm frustrated by Ruby's lack of strong typing, open module messiness, and the resulting lack of documentation (*). In my experience, Java's greatest weakness is the lack of closures, which makes many operations verbose and error prone. That might be the biggest reason I'm looking at Scala.
I am finding Scala on the surface to be beautiful and concise. On the other hand, the number of idioms, patterns, and rules that lead to WTF moments have been far more than I expected. For example:
scala> val line = "123abc"
scala> val Foo = """(\d+)(\w+)""".r
Foo: scala.util.matching.Regex = (\d+)(\w+)
scala> val Foo(a,b) = line
a: String = 123
b: String = abc
Ok, so there is an unapplySeq method on RegExp, which is called because of a "compiler trick" when this is on the left side of an assignment (or in a match). That performs an "extraction" on the right side and assigns the resulting List to the new vals passed into the constructor-like call. It's an interesting construct, and I'm still learning about its usefulness, but features like this make the language scary and unnecessarily complicated in simple cases.
Basically it's:
// Note: this doesn't work, since unapplySeq does not return a Tuple
val a,b = Foo.unapplySeq(line)
That makes a lot more sense to your average Bill, especially if we give unapplySeq a nicer name like, say, "match". Sure, there's some fancier stuff you can do with matches (the Scala kind, not the regexp kind,) although I'm not sure how much that buys you in most cases.
These types of tricks strike me as a violation of my keep-it-stupid-simple philosophy. Increasing the brainpower required to understand simple constructs unnecessarily is counter-productive. Perhaps that construct has it's place, but this doesn't seem to be it.
These complications are compounded by the tendency of Scala documentation to use rich examples instead of simple ones. For instance, the example for this in "Programming Scala" uses some advance type notation and for some reason introduces the Scala version of symbols, rather than showing a dirt simple example.
That said, hopefully I'll continue to be interested in Scala once I grasp all the concepts.
(*) If you think specifying an object type is too much work, you're unlikely to think documenting the type is much fun either. And if you're going to document the type, why not specify them programmatically? I digress.