Stack OverflowScala vs. Groovy vs. Clojure
[+676] [6] James Fassett
[2009-08-22 00:08:01]
[ scala groovy clojure language-comparisons ]
[ ]

Can someone please explain the major differences between Scala, Groovy and Clojure. I know each of these compiles to run on the JVM but I'd like a simple comparison between them.

[+872] [2009-08-22 02:39:22] Daniel C. Sobral [ACCEPTED]

Groovy [1] is a dynamically typed language, whose syntax is very close to Java, with a number of syntax improvements that allow for lighter code and less boilerplate. It can run through an interpreter as well as being compiled, which makes it good for fast prototyping, scripts, and learning dynamic languages without having to learn a new syntax (assuming you know Java). As of Groovy 2.0, it also has growing support for static compilation [2]. Groovy supports closures and has support for programming in a somewhat functional style, although it's still fairly far from the traditional definition of functional programming.

Clojure [3] is a dialect of Lisp with a few advanced features like Software Transactional Memory [4]. If you like Lisp and would like to use something like it under the JVM, Clojure is for you. It's possibly the most functional language [5] running on the JVM, and certainly the most famous one. Also, it has a stronger emphasis on immutability [6] than other Lisp dialects, which takes it closer to the heart of functional language enthusiasts.

Scala [7] is a fully object oriented language, more so than Java, with one of the most advanced type systems [8] available on non-research languages, and certainly the most advanced type system on the JVM. It also combines many concepts and features of functional languages, without compromising the object orientation, but its compromise on functional language characteristics put off some enthusiasts of the latter.

Groovy has good acceptance and a popular web framework in Grails. It also powers the Gradle build system, which is becoming a popular alternative to Maven. I personally think it is a language with limited utility, particularly as Jython and JRuby start making inroads on the JVM-land, compared to the others.

Clojure, even discounting some very interesting features, has a strong appeal just by being a Lisp dialect on JVM. It might limit its popularity, granted, but I expect it will have loyal community around it for a long time.

Scala can compete directly with Java, and give it a run for its money on almost all aspects. It can't compete in popularity at the moment, of course, and the lack of a strong corporate backing may hinder its acceptance on corporate environments. It's also a much more dynamic language than Java, in the sense of how the language evolves. From the perspective of the language, that's a good thing. From the perspective of users who plan on having thousands of lines of code written in it, not so.

As a final disclosure, I'm very familiar with Scala, and only acquainted with the other two.


(1) Nice one. Although I have to say Scala has Lightbend corporate backing and is used by big names like LinkedIn, Twitter, Spark and lots of banks. Where I work we have a codebase of 11 milions lines of Scala, which is not a good idea but it works. - Joan
[+219] [2010-09-16 22:01:55] Kevin Wright


Scala evolved out of a pure functional language known as Funnel [1] and represents a clean-room implementation of almost all Java's syntax, differing only where a clear improvement could be made or where it would compromise the functional nature of the language. Such differences include singleton objects instead of static methods, and type inference.

Much of this was based on Martin Odersky's prior work with the Pizza [2] language. The OO/FP integration goes far beyond mere closures and has led to the language being described as post-functional.

Despite this, it's the closest to Java in many ways. Mainly due to a combination of OO support and static typing, but also due to a explicit goal in the language design that it should integrate very tightly with Java.


Groovy explicitly tackles two of Java's biggest criticisms by

  • being dynamically typed, which removes a lot of boilerplate and
  • adding closures to the language.

It's perhaps syntactically closest to Java, not offering some of the richer functional constructs that Clojure and Scala provide, but still offering a definite evolutionary improvement - especially for writing script-syle programs.

Groovy has the strongest commercial backing of the three languages, mostly via springsource.


Clojure is a functional language in the LISP family, it's also dynamically typed.

Features such as STM support give it some of the best out-of-the-box concurrency support, whereas Scala requires a 3rd-party library such as Akka [3] to duplicate this.

Syntactically, it's also the furthest of the three languages from typical Java code.

I also have to disclose that I'm most acquainted with Scala :)


(11) I never heard of this Funnel language before. Thanks for filling a little gap in the historical record. - Randall Schulz
(8) You can't really call Clojure a pure functional language. Its certainly possible to write imperative code. - dbyrne
(1) Scala now has concurrent versions of most if not all collections built in. You don't have to write concurrent code, just use concurrent collections, and voila, concurrency. - GlenPeterson
(2) Scala has built in the Akka library for actor based concurrency. It is no longer a 3rd party dependency. - scott m gardner
Scala can't integrate as tightly with Java as tightly as Groovy as you can't integrate a Scala class into Java but you can integrate a groovy class. You can also write Java inline with Groovy - Orubel
(2) @Orubel In bytecode, a scala class is identical to the equivalent Java class - types and all. As a case in point, the entire Akka Java API is written in Scala. So please explain what you mean by "can't integrate" here - because it reads like FUD to me. - Kevin Wright
FUD? I'm looking at your own documentation. ( It's not FUD... Groovy doesn't have any of these issues. It's just the fact that it doesn't integrate well. - Orubel
(3) To summarize that document: "Scala features that don't exist in Java can't be directly used in Java". However... abstract type members and higher-kinded types are fairly advanced features that you're certainly not forced to use! Java also can't use methods without parameters, builders, or extension modules from Groovy, thus also making Groovy "not tightly integrated" by your own definition. - Kevin Wright
The funny thing is, a class in Java IS a class in Groovy; just change the extension. You can't do this with Scala. Scala is compatible at the bytecode level... Groovy is compatible at the class,object and primitive level making it FAR MORE compatible. - Orubel
@Orubel classes objects and primitives are all constructs at the byte-code level. Supporting these as first-class citizens is what it means to be fully compatible in byte-code. Java can use scala classes as though they were native (and vice-versa), including generics. - Kevin Wright
These convert to byte-code. They are supported differently in Java/Grails than in Scala and convert differently hence the difference in benchmarks when statically compiling. Otherwise you would get the EXACT SAME BENCHMARKS! - Orubel
@Orubel please do cite your examples of benchmarks that differ then - Kevin Wright
There are no full side by side comparisons but there are 'Scala vs Java' and 'Groovy vs Java' comparisons. These can easily be broken down into a pattern showing the relative speeds when using different patterns. See this article for examples :… - Orubel
(1) @Orubel YOUR article there is laden with anecdotes and in no way mentions the comparative benchmarking of how classes are translated to bytecode. It generally contains a lot of misunderstandings and outright (though unintentional) falsehoods. So much so that you're going to have to wait a bit for a full response, as a comment here really wouldn't do it justice. - Kevin Wright
Hello Mr Kettle. You obviously didn't look hard enough. - Orubel
(1) @Orubel - replied: - Kevin Wright
I dont see anything. Was there something important there? - Orubel
(1) @Orubel there's nothing there if you wish to see nothing (and then comment on it) Please, feel free to have the last word in this discussion, with my full blessing. - Kevin Wright
No... there really is nothing there buddy. Your content was removed by LinkedIn - Orubel
Do I have your blessing to have the highest ranking on Google for 'Scala vs Groovy' too? Does Google go through you too now? If so, thanks :) - Orubel
(1) Yes, you have my blessing to have accumulated a higher rank in 9 months, using an article titled with that exact phrase, than I obtained in 2 days with no promotion whatsoever, on content that received its latest comment 7 hours after it was allegedly removed. - Kevin Wright
Wow. You have some amazing imagination. I'm still number one ... but you'll always be number one in my heart, Kevin. :) - Orubel
[+68] [2012-04-03 13:59:09] Thai Tran

I never had time to play with clojure. But for scala vs groovy, this is words from James Strachan - Groovy creator

"Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."

You can read the whole story here [1]


(72) It should be mentioned that this statement is not saying that Scala is better than Groovy. James is also known for saying that if he had known how much trouble it is to create a language he would never had created one. Seen in this context it is clear why he wouldn't have developed Groovy then of course. And I dare to say he gave many good ideas, but he is not the creator of current Groovy. he left the project long before the 1.0 in 2007 and has no participated since then. There is at least as much without him in the project as there was with him. - blackdrag
(31) And given that James Strachan is working actively on the Kotlin language, Scala apparently isn't impressive enough for him. - bdkosher
(6) @bdkosher he's working on it because Scala is too impressive for the most programmers… and [more importantly,] in some places too complicated, too - Display Name
[+30] [2009-08-22 00:30:07] Mehmet Duran

They can be differentiated with where they are coming from or which developers they're targeting mainly.

Groovy [1] is a bit like scripting version of Java. Long time Java programmers feel at home when building agile applications backed by big architectures. Groovy on Grails is, as the name suggests similar to the Rails framework. For people who don't want to bother with Java's verbosity all the time.

Scala [2] is an object oriented and functional programming language and Ruby or Python programmers may feel more closer to this one. It employs quite a lot of common good ideas found in these programming languages.

Clojure [3] is a dialect of the Lisp programming language so Lisp, Scheme or Haskell developers may feel at home while developing with this language.


(24) Scala isn't really a functional programming language. It is an object oriented programming language first, with functional features. - Daniel C. Sobral
(16) I have to say, this answer feels a lot like a shot in the dark. I think a good case could be made that Python is closer to Groovy than to Scala, and Ruby is (in my opinion) not too close to any of the above, perhaps closest again to Groovy. Haskell is not too much like (Common) Lisp or Scheme (and thus not much like Clojure). To me, this answer feels (at best!) like "I don't know either, let me Wikipedia that for you". - John Y
(2) @Daniel I would argue that Scala is a functional language by most definitions. Actually, I have argued in the past (more than once) that Scala is not functional, but I have since modified that view. While it is true that some functional idioms are not as elegant in Scala as in other languages, the fact remains that all of the core features of impure functional languages (function values, immutability, currying) are present and idiomatic. This to me says Scala is functional and object-oriented. - Daniel Spiewak
(21) Scala is an imperative language with some functional features. If people continue to call a language functional as soon as it adopts idioms from the functional world then the term will become just another marketing term. Might as well start calling C++ functional and Haskell imperative. - jon hanson
I opened this post as a community wiki because generally there's no one single answer when you're comparing two languages. I've played around with all three of them but never really went deep with any. I was generally talking about the syntax and idioms. - Mehmet Duran
As with most comparisons, the truth is a shade of gray. If we are to believe the creator Martin Odersky, Scala was designed to be both object oriented and functional, with both paradigms being first class citizens. See his interview with Computer World for an answer in his exact words:… - alanlcode
(9) @alanlcode Odersky may say what he wants. Scala doesn't have any system to isolate side effects, it isn't lazy by default, and doesn't treat code as data -- it treats function calls as data, which is different. These are big problems if you want to be fully functional. On the other hand, Scala goes all the way to ensure its Object Model isn't flawed. I love Scala, but it's clearly functional second. - Daniel C. Sobral
(7) On the other hand, the ML family of languages is recognized as functional but is strict and allow side effects/imperative code. - GClaramunt
(2) @DanielC.Sobral I agree with some of what you say, although - assuming you count Haskell as a functional language - Haskell doesn't treat code as data either. In my very limited brain I'd say that's more a Lisp trait than anything. Haskell more treats data as code. - Rob Grant
@jon-hanson How could one possibly call haskell an imperative language? Scala and even c++ support a number of functional programming constructs. What features of haskell are imperative? Calling scala functional might be using the term a bit loosely, but calling haskell imperative is just plain incorrect. - Sean Geoffrey Pietz
(2) @SeanGeoffreyPietz Yes, it would be incorrect which is precisely my point. - jon hanson
@jon-hanson Your point is incorrect which is my point. You are making a false equivalence. - Sean Geoffrey Pietz
@jon-hanson Scala mixes functional and object-oriented/imperative paradigms and Haskell has no resemblance to an imperative language. So, calling Scala functional and calling Haskell imperative are not at all the same. - Sean Geoffrey Pietz
(2) My personal opinion after using all three languages is that Groovy is problematic. In the first place, I do not like dynamic typing. But after working in Groovy, I really don't like dynamic OO languages. One of the big things in OO programing is to create new types. The compiler does a great job of preventing me from passing the wrong type to a method call. It also makes sure that the method call has some documentation about what it expects as parameters, and what the method returns. Our code base is full calls like def runActivityReport(in, out) what in and out are nobody knows. - scott m gardner
I'd argue that even Javascript is a functional language. Sure, it supports mutability by default, until recently, but it can be written very successfully in pure functional style. More so than Python or Ruby. Of course it also has prototypal OO features too and often is written in a very imperative way. But it's rather silly to exclude a language from a paradigm just because it supports features not used in that paradigm. Such is the nature of multi-paradigm languages. - acjay
[+8] [2011-11-18 19:18:54] Jim Collings

I'm reading the Pragmatic Programmers book "Groovy Recipes: Greasing the wheels of Java" by Scott Davis, Copyright 2008 and printed in April of the same year.

It's a bit out of date but the book makes it clear that Groovy is literally an extension of Java. I can write Java code that functions exactly like Java and rename the file *.groovy and it works fine. According to the book, the reverse is true if I include the requisite libraries. So far, experimentation seems to bear this out.

That's the best book to learn Groovy. - topr
It's probably important to note that not all code will behave exactly the same. Some of these differences include the way in which Groovy understands single and double quotation marks and its preference for boxing over widening. Most code will work the same, though. - Ontonator
[+4] [2009-08-22 00:33:00] Thilo

Obviously, the syntax are completely different (Groovy is closest to Java), but I suppose that is not what you are asking for.

If you are interested in using them to script a Java application, Scala is probably not a good choice, as there is no easy way to evaluate [1] it from Java, whereas Groovy is especially suited for that purpose.


I don't understand your point about using Scala to script Java. You can certainly write a Scala script that drives Java code; no eval required. - Daniel Yankowsky
(2) @Daniel, please see the question about using Scala for scripting that I linked. The accepted answer there is that the lack of an "eval" facility and javax.scripting support makes it trickier to use Scala to script a Java application then it is with, say, Groovy. - Thilo