I agree that Scala will never be a good replacement for languages Ruby both because of its complexity and the fact that dynamic languages are always going to be more flexible than statically typed languages. The fact that majority of new languages are in fact dynamic ones is also a good indication of the inherent difficulty in designing a good statically typed language. Scala is a much grander project in scope than Clojure, Ruby, Python, Groovy, or pretty much any of the dynamic languages sprouting up on the JVM probably ever will be. For instance, because these languges are dynamic, they don't care to deal directly with things like the cost of autoboxing, the price of type erasure, the ugly hackery that is java arrays, and so on. Life is simple when everything is of type Object! Of course, this grander scope comes with a cost, and that cost is language complexity.
In my opinion, Scala's aim is to take on Java by providing a much more overall productive language than Java while still maintaining Java's performance. I feel it's very much akin to the goals of C++ versus C. Fortunately, the people behind Scala are well versed in PL theory and make sensible language design decisions, so at this point Scala is in little danger of someone writing an FQA on it any time soon.
Sorry, but this comment is pretty misinformed. Clojure has numerous facilities to address the performance issues you mentioned. You can, for example, annotate parameters to a function with type information to use primitives, java arrays, and remove the need for reflection.
Additionally, JRuby has had a JIT that attempts to do smart things to avoid unnecessary boxing and reflection. They've been rather impeded by the JVM on this front, but JVM 7 looks to open a lot of doors for the JRuby team to remove a lot of unnecessary dynamic dispatch in the execution of Ruby code.
The problem I see with Scala is it reeks of Perl 6's "everything and the kitchen sink" language feature-a-thon. Having learned Clojure and started Scala recently I'm constantly asking myself why Scala code has so much incidental complexity compared to the equivalent Clojure code. Often, it is due to the type system or the excessive number of constructs and syntax available in the language.
"All arguments are passed to Clojure fns as objects, so there's no point to putting non-array primitive type hints on fn args. Instead, use the let technique shown to place args in primitive locals if they need to participate in primitive arithmetic in the body.".
Also, I'm not an expert on JRuby's attempted optimizations, but if I understand correctly they are very limited, much in the same way that Java's escape analysis is. The post By Charles Nutter less than a year ago is illuminating in that regard(http://groups.google.com/group/jvm-languages/browse_thread/t...). Have things changed that significantly since then? I follow his blog regularly and in most benchmarks I can remember him talking about he still compares JRuby to Java running boxed math.
A language can be both static and dynamic. C# introduced the 'dynamic' keyword, and perhaps they'll go further with that idea in the next version. The Java 7 JVM will have the 'invokedynamic' instruction, plus a new Java API to manage it. Perhaps Scala will extend the language syntax at that time to allow dynamic typing, with that API underneath, for those few cases where dynamic typing's better.
A language that was dynamic first, then added the static, is Groovy and Groovy++.
In my opinion, Scala's aim is to take on Java by providing a much more overall productive language than Java while still maintaining Java's performance. I feel it's very much akin to the goals of C++ versus C. Fortunately, the people behind Scala are well versed in PL theory and make sensible language design decisions, so at this point Scala is in little danger of someone writing an FQA on it any time soon.