Within a comment thread over at StackOverflow, the user orubel directed me to this post (by a Mr Owen Rubel) in support of some strongly pro-groovy/anti-scala claims that he was making.  I felt that a great deal of the article was out of date, misinformed, or just plain wrong; and simply commenting there wouldn't do the subject justice... therefore this is my reply, in the style of the original article.

Scala VS Groovy: Multi-Paradigm Programming Showdown

... there is a lot of misinformation AND lack of information out there about functional languages for the JVM (such as the article that this is a response to). For example, did you know a far more powerful and feature-rich language exists called Scala?

Aside from being more popular than Groovy (one one site), and the only other JVM language listed in the top 20 most popular languages (on yet another site, that just so happens to support my claim, and isn't easily gamed by people prefixing mentions with "language" or "programming in"...), here are some facts presented for your consideration:

(in which I won't first try to bias you by using a phrase such as "reasons alot [sic] of companies use Groovy in place of Scala...")

Maturity

Scala was created in 2003 as a small project by an University in Switzerland (EPFL - Lausane) and in 2011, the creator received a government grant in recognition of Scala's strong support for concurrent/parallel programming on today's increasingly multi-core processors, this grant was used to create the company Typesafe.

Groovy was created in 2004 and the company was purchased by SpringSource (Makers of Spring, the most widely abused Java Framework), then purchased by VMWare and managed by Pivotal for the last several years before moving on to become an Apache project.  Since that time, Apache Spark (written in Scala) has shot to the forefront as Apache's most popular and committed-to project.

Groovy is integrated into Springboot, Android SDK, the Gradle build system and is used by Java and (occasionally) Scala developers every single day.  Then again... the original Java Date/Calendar library is used in these places too, perhaps one of the strongest possible demonstrations that an appeal to popularity is rightly classed as a logical fallacy.

Scala did not have the resources and funding that Groovy had in order to manufacture the same growth of community, yet it managed to thrive nevertheless... perhaps on its own merits rather than though advertising?  It is this kind of overt corporate involvement that stagnates a language, leaving v1 features present in deprecated form even in a v8 release and discouraging the community from developing libraries and plugins for it because they lack the "official" sanction that "enterprises" so often fall for.

Both languages have wide adoption across multiple areas and by companies such as Netflix, Twitter, Facebook, Amazon and others.  Groovy is stronger in places where it's used as a "scripting" or "glue" language atop a Java codebase, such as in log configuration, the Gradle build framework, and the Spock test framework.  Scala is more commonly used for entire applications and most notably in Big Data, where there is very little competition for its feature set.  Groovy is more popular in android development but both languages are capable here.

As an appeal to authority; Google uses Groovy in the Android SDK and even uses Groovy internally on several projects.  Google has not publicised any use of Scala, though I know a number of Googlers who are very active within the Scala community.

There's also some crossover where people use Gradle for Scala projects, but Groovy projects don't use Scala tools - because the programmers have generally already switched the entire project to Scala by the time they need that amount of power.  Groovy already has a robust community (as does Scala), an enormous library of plugins (as does Scala) and integration with Java, though not with types, not unless you use Groovy's 2.0 static compilation and don't need generics, Scala has a much better integration story here.

In this case, both languages have shown themselves to be mature and proven technologies. People TALK about and USE both Groovy and Scala through a variety of different tools, environments and even languages.

Points: Scala +1 and Groovy +0.5 (because it's mostly only used on the periphery of Java apps, not for building entire systems)

Object-Oriented Programming

In order to appeal to (and seem familiar to) C++ developers, Java used the C++ model of having primitives and classes with static members.  This is not true OO programming as a Smalltalk programmer would understand the term.  Primitives are NOT objects and static members are little more than procedural name-spacing.  There are also oddities such as operators only being available on primitives (which can be special-cased as non objects) except for the doubly-special case of +, which is also available on String object.  It would be better to describe the paradigm as class-oriented-with-warts than as object-oriented.  Groovy inherited the same model; again, for reasons of familiarity.

Scala sidesteps this entire mess by treating all values as objects (functions and primitives too) and by using singleton objects in place of static members.  Singletons have the advantage of being true objects, fully able to inherit from traits, overload members, and participate in polymorphism.

Scala also supports both generics and type classes, allowing it to use both parametric and ad-hoc polymorphism in addition to subtype polymorphism.  Scala's declaration-site variance is also easier to use than Java's use-site variance.

Both languages support traits, thus allowing for a controlled form of multiple inheritance that uses linearisation to avoid the diamond inheritance problem from C++

Points: Scala +3 and Groovy +0.5 (one point for each form of polymorphism supported)

Functional Programming

Both Groovy and Scala are considered 'impure' functional language implementations, given that they both support imperative logic with side-effects.  The functional paradigm is orthogonal to OOP, so it's perfectly possible for a language to implement both.

Crucially, both languages are able to work with functions as first-class entities, assigning them to values, currying and partially applying them, composing them, memoizing them, tail recursion, and trampolining. 

That said, Scala supports more functionality generally associated with FP, such as:

• pattern matching (object destructuring, nothing to do with regular expressions)
• immutability by default
• higher-kinded types
• type classes
• Tail-call optimisation by default (the @tailrec annotation only serves to verify that this optimisation is performed, it'll be done anyway if possible)

Although Scala succeeded the Funnel language, it was always designed to fix Java's many flaws whilst maintaining Java compatibility from day one, including full support for OOP and compiling down to bytecode as similar to Java's as was possible.  This was specifically done to support full interop with Java libraries and tools.

Groovy, on the other hand, was always just a layer on top of Java and aimed to be 100% compatible at the source level, then adding FP and other syntactic sugar to the language.  This neatly allows one to avoid some of Java's worst verbosity, but means that you still retain many of Java's flaws.

There's crossover here, but clearly Scala is attempting to make fundamental fixes to issues that Groovy tries to simply paper over. 

Points : Scala +2, Groovy +1

Concurrency, Futures and Actors

Scala has the thriving Akka library built into the standard library now.  This offers STM, Actors, Remote Actors, Agents, Dataflow, Futures and Promises.

Scala also has Spark, for machine learning and parallelising work across some truly massive clusters.

Groovy has GPars, which hasn't seen a release since 2014

Points : Scala +3 (+1 for Akka, +1 for Spark, +1 for being active), Groovy +1 (for GPars)

Compatibility with Java

Both languages can consume Java libraries without problem.

Both languages offer features that are not available to Java, if you avoid these features in public APIs then Java will happily consume libraries written in either Groovy or Scala.

Scala has a slight advantage here in exposing types that javac can use, most especially with generics.

Groovy has a slight advantage that you can declare your class as Groovy and write almost 100% pure Java INLINE. Yes... The exact same 100% Java syntax that you loved so much that it drove you to investigate replacements like Scala and Groovy.

Points : Groovy +1 and Scala +1

Developer Knowledge

Finding developers who know or who have worked with Scala is allegedly hard. As a many Scala developers will be happy to tell you, the ramp up time to full Scala knowledge is high (though you can reach productive parity vs Java in about two weeks, growth beyond that point is then making you more productive than you'd be in Java). Ask a lot of Java developers if they have used Groovy and 50% of them will tell you yes... and that they had FUN with it or they enjoyed it.  A great many developers will say similar things about Scala and also go on to add that they felt empowered.

Most Java devs already have a pre-existing knowledge of Groovy from existing tools, prior experience, scripting in Java or just plain curiosity.

Scala on the other hand often requires retraining staff in a new way of thinking rather than just directly making use of their existing skills and knowledge. This is where a lot of people have issues with learning Scala and hence why people often complain of its huge ramp-up curve on learning the language, there's actually new stuff to learn and old bad habits that need unlearning.  Resistance to change is just an aspect of human nature and needs to be worked through, ask any parent of a potty-training child how difficult this can sometimes be.

Groovy is merely a 'layer' on top of Java and is so similar at times that 99% of Java code converts straight over without requiring changes. This allows Java developers to just sit complacently on their laurels / existing knowledge.

Then again... If you need to solve the sort of problems that Scala excels at, hiring a Scala developer means you've very likely just hired a person already familiar with that kind of problem; an invaluable head-start!

Points : Groovy +1 and Scala +1 ... honestly, choose the right tool for the job. Being able to easily recruit lots of people beneath you is a political decision, not a sound technical one

Flexibility

While Scala is statically compiled and has a rich type system able to enforce a great many invariants at compile time, Groovy is dynamically typed by default with type hints validated at runtime; you need to remember to enforce static compilation at runtime through @CompileStatic.  Most Groovy developers actually write static code as it compiles better anyway; The @CompileStatic annotation can be added as a bean if wanted so you don't have to add to all classes or on a per class basis.  This is a legacy thing as compileStatic didn't historically exist in Groovy, and changing to static-by-default would break existing codebases.

If necessary, Scala has a Dynamic type, it also has a type-safe macro system allowing you to solve many of the same problems, but without sacrificing anywhere near as much safety.

It is for this reason that Groovy has found a niche as a scripting language.

Points : Groovy +1 (unsafe by default) and Scala +2 (explicitly opt-out of safety, or use macros)

Syntax

Scala developers will often freely admit that Scala has a high learning curve vs Groovy which has a very short learning curve... and most of this is due to acquainting yourself with the new an powerful concepts that the language has to offer.  To claim that this is simply about 'syntax' is missing the point by a wide margin.

With Groovy, the syntax from Java - flaws and all - was maintained and so this syntax is also very similar to other languages like Python, Javascript, Ruby, even C. In Groovy, valid Java syntax is valid Groovy syntax.

But Scala decided to drastically change a lot of its syntax to be more in line with type-inferred FP languages, and better fit-for-purpose.  Moving type declarations after value names makes a lot of sense when those types are often optional, more so when types get longer if using powerful constructs such as HLists, existential types, or higher-kinded types.  This is a change that Java developers must learn, but it was made for good reason!

In Scala, you spend a lot of time learning new concepts alongside the new syntax and improving yourself as a programmer. In Groovy, you transfer the skills you already have.

There's a trade off here between true improvement and the comfort of familiarity.  Lacking context, neither choice is inherently better.

Points : Groovy +1, Scala +1  

Speed

Groovy is historically very slow to run, partly due to dynamic typing and mostly due to making all numbers BigDecimals.  Static compilation has improved this situation a great deal.

Scala is historically very slow to compile. Incremental compilation and compiler enhancements have improved this situation a great deal.

In actuality, you'll always find benchmarks online showing your favoured language to be faster... take them with a grain of salt.

Scala can be easier/faster to maintain, with richer types catching more issues and providing more self documentation of code.

Groovy has a faster compile cycle, but needs more unit tests.

Take your pick... 

Points : +1 both

Frameworks

Both have good frameworks to support them but Groovy's Grails Framework is based on Spring which is VERY mature and the most popular and well supported Java framework.  Consider again the popularity, maturity and well-supportedness (it's in the standard lib) of java.util.Date before judging whether or not this should be automatically accepted as a Good Thing™

In a 2014 rating of Java frameworks by Matt Raible, He observed that Scala's Play framework is more popular than Grails, and that Pivotal are pulling financial support, perhaps due to declining popularity?

And Spring support for Scala was dropped awhile ago due to lack of support (for Spring, not for Scala); it was only ever so recently picked up by a solitary developer and exists in a broken buggy state.

And now Grails has even extended Spring-Boot microservice... Whereas Play avoids servlets and provides its on highly-asynchronous framework based on Netty.  Please judge this information based on how negative a viewpoint you have of Spring (many developers point to Spring as a disaster of a framework, and consider any association with it to be a negative taint).

The most popular project on Apache is Spark (which is Scala-based).  Thus giving you a choice of authorities (Spring or Apache) to appeal to, if that's your favourite logical fallacy...

Points : Groovy +1 and Scala +1 (an easy answer, and I'm getting lazy)

Test and Deploy

Groovy has some great test and deploy tools that have become a standard in the Java community: Gradle is now built into the Android development toolkit and is even used by Ruby and Python developers for it's easy build and deploy.

Spock, a testing framework built in groovy, has become enormously popular in the Java community as well and has started to replace the standard jUnit in most developers toolkits.

ScalaTest is arguably one of the most powerful and richly-featured test frameworks on the JVM, taking full advantage of Scala's Internal DSL capabilities.

SBT has hundreds of plugins, it's now trivial to take a play webapp, compile down JSX files, optimise commonJS imports, package and publish to a docker repository using a single command.

These tit-for-tat comparisons are starting to get silly now.

Points: Groovy +1 and Scala +1 (equal points again, I really can't be bothered to make up yet another set of scoring criteria)

Big Data Development

Because I'm picking arbitrary categories at this point just to make my case, the Groovy chap favoured Mobile development here.

Points: Scala +1

So Why Does Scala Appear Higher In Language Rankings?

Because it has a higher rate of adoption, more projects on StackOverflow, and more people are discovering it through Apache Spark.

SCORES:

Groovy: 10 points

Scala: 18 points

It's my article, the numbers and topics I chose are arbitrary and subjective.  Is it any surprise that they added up to say what I'd already decided before writing it?

Final Thoughts

The very premise of this article, and the article it parodies, is false.  The idea of comparing Scala vs Groovy as replacements for Java just doesn't play out in the real world.

Scala is very definitely used as a full replacement for Java, with many pure Scala frameworks visible on GitHub.  Groovy is only very rarely used like this; instead, it's found a home as an adjunct to Java, used for peripheral tasks such as DSLs for building, logging and testing in codebases that otherwise still have their core written in Java.  Attempting to do a like-for-like comparison completely misses this big difference in the way the languages are actually used.

But remember folks... This is in large part a response and a parody, please don't take anything that I wrote too seriously!