Scala is more statically typed then Java. It's not a dynamic language, type inference (what makes it look like Ruby to some) is done by the compiler. Modern (i.e., based on concepts dating back to late 70s and 80s instead of 60s and early 70s) statically typed languages don't have to the have the verbosity of Java and C++: see F#, OCaml and Haskell.
It does use reflection for certain types of pattern matching (only similarity with the JVM dynamic languages), but I'd expect most of the issues (note: I haven't tried myself) are due to the Scala compiler specifically targeting HotSpot.
It doesn't matter how static Scala or any other language is, all that matters is how well its type system fits into the target VM, and Java VMs are optimized for Java.
When the type-system doesn't fit you have to resort to workarounds, like allocating more objects than you should, or using introspection, or generating bytecode at runtime.
The JVM does fine here, but Dalvik is a VM created for a restricted environment.
That said, I don't think static languages should have problems ... as long as they don't stray too far from Java ... like being lazy or having type-classes.
> Modern ... statically typed languages don't have to the have the verbosity of Java and C++
They don't have subtype-polymorphism either (basically OOP).
Since you mentioned OCaml and F#, you should take notice that the OOP subset doesn't support type inference when you're dealing with interfaces, that's because it is not possible. OOP was designed for dynamic type-systems, and it mixes with static typing like oil and water.
Also Scala's type inference is really restrictive and should't be in the same league as any other language with a Hindley-Milner type inference system.
The type inference is really useful when you're dealing with parametric polymorphism. Scala doesn't really have that either ... generics only save you from explicit type-casts, nothing else, and are a far cry from Haskell's type-classes or C++'s templates (which are late-bound). The recently introduced Manifests or the implicit conversions save you in many cases, but those are just ugly hacks that only solve certain use-cases.
I really don't get why Scala is so popular. It's as if people are so tired of Java that they are looking for a way out, willing to compromise just for some syntactic sugar.
It's interesting to note that none of the issues of subtype-polymorphism (tight coupling) or those of parametric polymorphism (hard to get right) are of importance to dynamic languages. In a dynamic language polymorphism is simply implicit.
That's why I hope people will invest in VMs that support dynamic languages in the future ... static typing is a bitch to get right, and it would be easier if the VM wouldn't impose a strict type-system on you.
First, this is an excellent comment and should have a much higher score than my fanboyish original :-)
I agree that Scala is restricted by the JVM (and the aim of full compatibility with Java) and as a result type inference, pattern matching and more suffer heavily. F#, OCaml and Haskell are better examples of modern type systems as they're less encumbered. I am fairly curious about how F# works around the CLR (or rather, how much CLR accommodates type systems different from C#'s), guess it's up to me to RTFM.
> It's as if people are so tired of Java that they are looking for a way out, willing to compromise just for some syntactic sugar.
I think this hits the nail on the head, but I don't see it as a bad thing. If there's a very strong reason to be on the JVM (e.g., other projects or libraries, operations preferences), it's nice to have an option that lets one have a more productive and enjoyable experience.
There are times where it feels like a big compiler hack (which it is), but first class functions (even if they're compiled down to anonymous classes), closures, optional lazy evaluation, type inference, limited pattern matching, case classes, traits/mixins, "encouraged" immutability, the collections, etc... add-up.
There are occasionally bugs and performance issues with compiler and the collections library, but overall I don't see what's compromised compared to programming in Java itself. I'd argue syntactic sugar classification applies more to Java 7's planned closures and first class methods.
> OOP was designed for dynamic type-systems
Yes, that's literally true. OOP feels natural in dynamically typed languages, even when it's bolted on (CLOS in Common Lisp, Perl 5).
It's still a mystery to me why Java "won over", given that Smalltalk had (at the time) better performing virtual machines (compared to older JVMs which were superceeded by HotSpot, which was originally used by Strongtalk) and great tooling. There are known examples of teams of inexperienced programmers working under guidance to produce large, well working projects in Smalltalk.
> That's why I hope people will invest in VMs that support dynamic languages in the future ... static typing is a bitch to get right, and it would be easier if the VM wouldn't impose a strict type-system on you.
Clojure, in my view, suffers the most from the type system that the JVM imposes. It would be interesting to see if Clojure and Scala would eventually target less restrictive VMs (reverting to compiler hacks on the JVM to functionally emulate these VMs).
It's still a mystery to me why Java "won over", given that Smalltalk had (at the time) better performing virtual machines (compared to older JVMs which were superceeded by HotSpot, which was originally used by Strongtalk) and great tooling.
It's very simple. Smalltalk was expensive. Students, hobbyists, people working at cheap corporations, startups, open source projects, and the like couldn't write, share, and distribute working systems on it.
I understand there were some good vendors with steep student discounts and the like. My roommate loved some of them. But he could not hack with friends for free (or even very cheap) on it.
And that little bit of money makes all the difference. Not that it would have taken off otherwise; there are many factors, but no language or VM that charges for access has taken off in a generation except where access to hardware is strictly limited by law (smartphones) or expense (FPGA, large scale microcontroller projects).
It's very simple. Smalltalk was expensive. Students, hobbyists, people working at cheap corporations, startups, open source projects, and the like couldn't write, share, and distribute working systems on it.
In fact, it was the deliberate strategy to become a "boutique" language, a secret weapon of the Fortune 500. The Smalltalk companies missed out on "The Bazaar" and the mindshare benefits of an open community.
It does use reflection for certain types of pattern matching (only similarity with the JVM dynamic languages), but I'd expect most of the issues (note: I haven't tried myself) are due to the Scala compiler specifically targeting HotSpot.