I’ve been seeing a surprising trend in the articles that have come through my feed reader recently: evaluating JRuby, Groovy and Scala for use as primary languages in new, on-JVM projects. This seems to be the new and trendy thing to write about. I suppose it’s not really surprising that each of these languages is receiving such attention, they all deserve it. What is surprising is that they are all put on the same playing field. Of the three, only Ruby and Groovy are actual peers in terms of capability and design. Syntactic differences aside, both languages do roughly the same things in fairly similar ways. Scala on the other hand isn’t even in the same league.
This is about the point that most comparison rants conclude by saying “Scala is statically typed therefore it is completely different. QED.” We can actually go a bit deeper though. Scala’s entire philosophy and reason for existence is divergent from dynamic, so-called “scripting” languages like Ruby or Groovy. Scala is designed to be a mid-level, general purpose language. By “general purpose” I mean something suitable for writing large applications, enterprise class stuff, etc. Not suitable for writing operating systems or for creating quickie scripts. In short, Scala is a peer for Java more than it is a peer for Ruby.
What I think is interesting is that Scala has a number of features which make it appear to be a dynamic language (such as implicit conversions, flexible syntax, type inference, etc). These features give Scala the “feel” of a dynamic scripting language like Ruby without really sacrificing the strengths of the compiler and static typing. It seems that this illusion is so effective as to actually have fooled most people into lumping Scala in with the dynamic crowd. While this is good in the sense that Scala is getting more attention this way, it also leads to a rising misconception of what Scala is and what it’s good for.
Ironically, many of the use-cases being presented in these language comparisons are best solved by a mid-level language like Java or Scala, rather than high-level languages such as Ruby, Python or Groovy. This actually seems to be leading to even more trouble in the world of language choice as the problem domain itself becomes blurry. Many developers these days are trying to apply Ruby to large desktop application development, or (just as bad) apply Java to simple CRUD and RAD applications. It’s the old adage: if all you have is a hammer, every problem looks like a nail. Developers are starting to select languages based on “what’s hot” rather than what offers the most effective solution.
The rampant number of Ruby-Groovy-Scala comparisons is not the problem, but rather a symptom of a greater problem: language overload. Even confining our search to the JVM, we can find so many wonderful languages of every size, shape and type-system. All of these languages have their creators pushing their product as the solution to life, the universe and everything. With so much noise pervading the language arena, it’s easy to see why many developers get confused when performing that crucial selection of tools.
Unfortunately, there doesn’t seem to be a “nice and easy” solution to the problem of language selection noise. Every language will always have its proponents, people who try to sell the language as the cure for life. Getting them to just shut up and realize the imperfection of their product is just about as likely as convincing the masses not to listen to them. So it seems that for the foreseeable future, we will continue to see rants, comparisons and rationales taking languages X, Y and Z out of context and attempting to come to a sane conclusion.