Scala vs.Clojure, part 3 – the similarities

There is some more discussion of Scala vs. Clojure. With the Oracle deal, and some discussions about the slow Java 7 release, it looks like Java is detoriating faster not slower. So discussions about Java succession increase. I've discussed Scala vs. Clojure here, here and here. Greg Osuri now adds his take in "Scala Vs Clojure", What the market thinks and compares job numbers for Clojure and Scala.

What I found interesting was a comment to that post:

I'm not really sure why Scala and Clojure are always discussed side-by-side. Sure, they're both relatively new languages and they are both on the JVM, but Scala and Clojure have vastly different philosophies.

Scala and Clojure are indeed very different, so why compare them? I've wondered the same in the past, because, hey, they just don't look alike. And nothing less than "different philosophies". As Jesper on Stack Overflow writes:

Note that Clojure and Scala are two totally different types of programming languages - Clojure is a functional Lisp-like language, it is not object oriented. Scala is an object oriented language which has functional programming features.

But then why are they compared and mentioned together? To some, Java looks to need a successor - see my Is Java dead? analysis - both languages have enough momentum to be discussed as one (contrary to Fan for example). Both are functional languages, both support objects, both favor concurrency. So they are remarkly alike. Only on the first look are they quite different, as Scala favors C style syntax for OO and FP while Clojure favors Lisp style syntax. But that's only lipstick.


In detail, Scala and Clojure look quite similar:

  1. Scala and Clojure are more alike than different
  2. Both have a strong focus on functional programming
  3. Both favor tight Java integration and basing apps on Java libraries (with wrappers) - with Clojure having a little bit more autarky tendencies
  4. Clojure more Lisp style, but with objects (see protocols)
  5. Scala more C style, but with functions
  6. Both favor persistent collections (immutable)
  7. Both favor new ways of concurrency, STM (Clojure) vs. actors (Scala), but both support the other mechanism with agents in Clojure and STM in Scala or Scala CCSTM


So you might wonder, with all those similarities, is it only a syntax thing? I might concur yes. You can think the same way in both languages, what you perhaps choose are differently thinking communities. The major difference is that Scala has very powerful type system - if you're into that type of thing - Clojure is loosly typed, but can have type hints - also see here. There is a strong type focus in the Scala community, influenced by early adopters.

Hope this helped to clear some things up.

If you liked this post, might also be interested in some other post I wrote about the topic:

Anatomy of a Flawed Clojure vs. Scala LOC Comparison

Update: The author of the post did the same biased LOC counting with Python vs. Clojure - Dhananjay Nene has a nice post about the Clojure/Python comparison Update 2: He did it with Java and PHP too. What a diservice to Clojure.

I've came across an article comparing Clojure and Scala. As I've did one too (Part 2) I'm naturally interested in the topic. But the article turned out to be FUD. Wikipedia says about FUD:

Fear, Uncertainty, and Doubt (FUD) is a tactic of rhetoric and fallacy used in sales, marketing, public relations, politics and propaganda. FUD is generally a strategic attempt to influence public perception by disseminating negative information designed to undermine the credibility of their beliefs.

Does the appearence of FUD articles mean the language war did start? I think both Scala and Clojure appeal to different audiences, but both seem in the race for replacing Java as the next mainstream thing (@headius no I don't think JRuby is the next Java thing, although you do excellent work with JRuby - I believe it's the next Ruby thing).

In the sense of Hacknots Anecdotal Evidence and Other Fairy Tales essay, I try to give some thorough criticisms and new facts concerrning the original blog post. Hacknot writes:

"As software developers we place a lot of emphasis upon our own experiences. This is natural enough, given that we have no agreed upon body of knowledge to which we might turn to resolve disputes or inform our opinions. Nor do we have the benefit of empirical investigation and experiment to serve as the ultimate arbiter of truth, as is the case for the sciences and other branches of engineering - in part because of the infancy of Empirical Software Engineering as a field of study; in part because of the difficulty of conducting controlled experiments in our domain. Therefore much of the time we are forced to base our conclusions about the competing technologies and practices of software development upon our own (often limited) experiences and whatever extrapolations from those experiences we feel are justified. An unfortunate consequence is that personal opinion and ill-founded conjecture are allowed to masquerade as unbiased observation and reasoned inference."

1. Are the lines of code really that different?

I'm very interested in Lines of Code (LOC) comparisons, as I've learned a lot from my LOC comparison of Java and Python (2x to 4x more LOC in Java). The numbers the author gives are:

  1. Scala 54
  2. Clojure 19

The difference in LOC looks to be on a big part due to missing library calls in Scala. Scala is missing a using and writing/reading to a file. While the using is part of my standard toolkit in Scala project, I must admit I do not know of a widely used library which provides such a method (perhalps scalaz or scalax?).

The reading of files is something different. Reading a little about Guava, would have made it clear that it doesn't make sense - at least in Javaland - to compare LOC based on missing library functionality.

Using Guava

List[String] lines = Files.readLines(file, Charsets.UTF_8);

instead of

implicit def file2String(file: File): String = {
  val builder = new StringBuilder
  using (new BufferedReader(new FileReader(file))) { reader =>
    var line = reader.readLine
    while (line != null) {
      line = reader.readLine

results in 1 line of code compared to 11 - 10 lines too much in the Scala example. Or as some have pointed out, using fromFile in Scala io makes the example as short.

Beside that, there is plainly code missing in the Clojure example compared to the Scala one. I've thought I might be wrong, comparing LOC and then just leaving out lines looked too apparent a flaw, but the code isn't the same it seams. Time measurements, comments and println are just left out: at least 7 lines of code.

2. Micro benchmarks are most often flawed

Everything that has been said before about micro benchmarking, and it seems has to be said to each new generation of JVM developers, applies:

Toward the end of writing high-performance code, developers often write small benchmark programs to measure the relative performance of one approach against another. Unfortunately [...] assessing the performance of a given idiom or construct in the Java language is far harder than it is in other, statically compiled languages.

The Java VM is a strange beast, with startup times, hot spot inlining, escape analysis and compiler optimizations. Writing the code a little different, makeing loops a little larger might make the code much faster - or slower. So all micro benchmarks on the JVM must sceptically analyzed and questioned.

3. Too much type annotations in Scala?

The next claim about Scala is the excessive usage of type annotations, or said differently:

As a Scala developer you spent much of your time writing out variables types which must be tedious, [...]

When counting all type annotations (not the object constructors) I end with 150 characters of source code.

Map[K, V]
[K, V]
Tuple2[K, V]
Tuple2[K, V]
[String, Int]

Compared to 2039 characters of the whole script, this results in 7.4% type annotations in Scala. Not something I would call "much of my time" - indeed only 7.4% of my time writing code, which in itself is only a small part of development.

4. Other criticisms

There are more lines of code missing in the comparison. As one comment noted:

More … the Scala code does som checking to see if the file exists or not. Your Clojure code does not do that. That will bump up the LOC by 4 – 5 lines i guess

to which the author replies

In regards to checking if the directory exists, its a matter of adding (when-let (dir (file-seq …)) 🙂

But don’t read this as the authoritative comparison between Ruby and Clojure, it’s just a fun little exercise.

Two remarks: Exactly, the line is missing and should be have been added from the beginning. The title, tone and content of the post - especially on the insistence that Clojure is both faster and has less LOC - doesn't reflect the "fun little exercise" but looks quite serious.


The conclusion is simple. Comparing languages based on LOC is a dangerous thing and shouldn't be taken lightly. The comparison is flawed, the Scala example could be reduced by 17 LOC (an astonishing 31%) and the type annotations are not "much of the time" but only 7.4%. Keep comparing languages, but based on facts and rigorous maths, not on FUD. Said that, if you find flaws in my post I would be glad to correct them.

Clojure vs Scala, Part 2

Photo by PhillipC

There are two languages stirring up the Java World: Clojure and Scala. Clojure a Lisp dialect on the JVM, powerful and pure and the Scala language a tight integration of object and functional programming. Which should you learn? Matt is wondering:

The two leading candidates in the JVM/concurrent/multicore arena seem to be Scala and Clojure. [...] Scala is a multiparadigm language, supporting both object-oriented and functional constructs. It is statically typed, yet offers very nice type inference. Clojure, on the other hand, is a functional Lisp derivative with almost no OO constructs that is dynamically typed. Both are designed to enable concurrent programming. Which one do I choose?


Clojure as the first contender to the Java throne came out of nowhere and conquered the blogosphere in a storm.

Clojure [...] is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. [...] Clojure provides easy access to the Java frameworks [...] Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system.

There is some traction with companies already, FlightCaster who predict flight delays use Clojure for backend code:

The research and data heavy lifting is all in Clojure.

Some obvious reasons that speak for Clojure:

  • Big momentum, mainly in the dynamic language (Ruby) avant-garde and in Lisp circles
  • LISP community
  • STM, software transactional memory, an easy way to share data
  • Very clever immutable datastructures
  • Well thought Seq concept, tightly integrated with Java

Depending on your standpoint there are some downers with Clojure:

  • no objects (might not be a problem for you)
  • hard to read for C tradition developers, this does include the many (), prefix notation and functional programming style in Lisp
  • no Lisp skills in most companies, harder to recruit than Java or Scala

Clojures Java Integration

Although it does not possess objects, astonishingly Clojure has excellent Java integration. This might be because one of the main arguments of Clojure it makes against other Lisp dialects is the Java plattform. So it does make a lot of sense of excellent integration.

  • Java methods as functions in Clojure
    (map (memfn charAt i) ["fred" "ethel" "lucy"] [1 2 3])
  • Collections in Clojure implement Collection
  • Functions implement Callable and Runnable
  • "Core abstractions, like seq, are Java interfaces"
  • "Clojure seq library works on Java Iterables, Strings and arrays"


Scala is the rising star on the JVM. James Strachan, the inventor of Groovy writes: "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." Though one must admit the Groovy back than is not the Groovy from today. The question remains: What is Scala?

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application.

The main reasons for using Scala:

  • Big momentum, mainly among Java developers
  • Java community
  • Has objects (might not be a plus for some)
  • Very powerful type system
  • Object oriented and functional integration

Some downers:

  • Functional programming can be difficult to understand for a Java developer
  • The type system is more complex than the Java one (might be a plus for you)
  • Actor concurrency in Scala is nice, STM feels more natural to lots of problems (shared state vs. agents), Akka could help
  • Scala is very powerful, some developers might shoot themselves into the foot

The biggest promise of Scala nevertheless is power and terseness. As I've showed in "Top 5 Things to Know About Constructors in Scala", Scala has much less boilerplate code. This example in Java:

 public class Foo() {
   private Bar bar;
   public Foo(Bar bar) { = bar;
   public Bar getBar() { 
      return bar; 
   public void setBar(Bar bar) { = bar;

can be written in Scala in one line:

class Foo(@BeanProperty var bar:Bar)

Which is important, to a degree that you should drop setter and getters if not needed. I wrote in "Go Ahead: Next Generation Java Programming Style":

If you have simple data holders or data transfer objects, don’t write boiler plate code with getters and setters. I know this is heresy in Java, but just use public fields.

Scalas Java integration

Scala has good, but compared to Clojure a rather basic integration. One can implement Java interfaces in Java, extend Java classes and vise versa. Scala isn't tightly integrated on the API side - only with some in this context clumsy, unneeded Meta-Programming with impliciets. Scala promises Clojure like Collection integration with Java in the future - we'll see. From the Java side things also do not look as nice, Scala classes and traits have lots of ugly named methods, until IDEs know how to deal with this, code completion is spammed by Scala.

As a side note, Groovy has also deeper Java integration that leverages the dynamic nature of Groovy. For example the "as" keyword.
With as closures or maps can easily be coerced to a Java interface. This goes beyond the Scala way of implementing interfaces.

def readable = { it.put("12 34".reverse()); 5 } as Readable

Nice, wish to have this in Scala - the map version if as will be hard to make play nice with static typing.


Andrew Glower wrote last year:

Is Scala or Clojure poised for stardom? Can two languages co-exist as stars or does one invariably outshine the other? If history is any indication, then I’d venture to guess that the answer is that both can’t be stars– just like both Groovy and JRuby aren’t stars. They co-exist and, in truth, divide the market and have followers with strong opinions on both sides. Thus, if I had to guess right now, I’d say that Scala has the edge with some good momentum.

I concur. The conclusion might not be what you want to hear. Draw your own.

Clojure has a lot of appeal to me, it looks so clean, the Java integration has such a pure feel, hard to describe. I do not buy the argument that Lisp is so much more powerful than e.g. Scala - so this doesn't influence me much. And Clojure as a Lisp dialect is way out of the mainstream. It will make it hard to recruit developers - do not listen to people who declare this a non issue. I've been recruiting Java developers for years, and it's hard. It's much harder for Clojure.

Scala isn't as pure as Clojure, not as en vogue. But it is pragmatic and powerful. It has a lot of momentum now and is easily learned by Java developers - at least by those that are open enough. The good ones usually are. The main promise and reason for Scala is how much less lines of code you need than in Java. Less code, less bugs, easier to read - to some extent - and faster to write, leading to higher productivity. Who doesn't need higher productivity with the same safety as Java?

Which should you use in your company? Daniel warns on Stackoverflow, in "Scala vs. Groovy vs. Clojure":

It's also a much more dynamic language than Java, in the sense that the language evolve. 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 on it, not so.

You need to decide on your own. Which would I use? Scala. Which should you learn? Both obviously.

What is your plan?

ActiveMQ vs. Jabber

If you have or plan an application with synchronous communications over an external API, it will sooner or later break. Why do we need asynchronous communications? Matt Tucker is clear about that:

Take, for example, Twitter. High Scalability recently covered the load stats on Twitter reporting that they average 200-300 connections per second with spikes that climb to 800 connections per second. Their MySQL server handles 2,400 requests per second! Recently, the [2008] Macworld keynote became the most recent culprit for causing Twitter to cut off its API, which has 10x the load of their website.

When one of my web pet projects needed a messaging backbone which extends to the browser. Whenever a resource did change on the server, all users watching the resource should get a notification without need to reload their browser. Two candidates are Javascript for ActiveMQ, which uses Comet

ActiveMQ supports Ajax which is an Asychronous Javascript And Xml mechanism for real time web applications. This means you can create highly real time web applications taking full advantage of the publish/subscribe nature of ActiveMQ.

ActiveMQ is a messaging bus, often used as an Enterprise Service bus as mentioned in my recent concurrency rant. Components can send messages to the bus and subscribe to topics.

Creative Commons License photo credit: mudpig

The other unsuspected contender is Javascript for Jabber. Jabber with the XMPP protocol is usally used for sending chat messages. Comparing these two and my thoughts:


  • Standard solution, JMS based
  • Routing solutions like Camel available
  • Easy access for different languages via Stomp
  • Attach Jabber as a service
  • Notification easily over topics


  • Free OpenFire server
  • Messaging with only one user with UUID for resource which did change
  • Messaging with many users, who join one chat room
  • Chat rooms as topics
  • Server side filtering? How to make it secure, that people only get their own messages?

In the end I decided to go with Jabber/XMPP. The main points for me have been:

  • Server does scale to connections
  • Chat client can be used for debugging
  • Very easy to use with different programming languages
  • Presence protocol to detect services
  • Easy to implement additional chat solution

This worked quite well as a spike. I followed a similar mode as Adrian Sutton, who had good experiences with Jabber/XMPP too when spiking a cache solution:

We grabbed the Smack API and started playing with it and quickly discovered that sending and receiving messages was ridiculously easy. It turns out that the absolute simplest way you can minimize stale data in your caches is to simply have all the servers join a preconfigured chat room. Whenever they save a change to a resource they send a message to the room with the unique ID of that resource and whenever they receive a message from the room they assume it's a unique ID and remove any cached versions of that resource.

Though I had some major problems accessing Jabber consistently from Javascript. With more on messaging in the backend, I would have went with ActiveMQ as a message bus. And perhaps I might move to ActiveMQ in the backend and then I'm still free to attach Jabber on top of that and keep the frontend code. Best from two worlds.

Think innovative, use technologies in a way to help you. Jabber/XMPP is more than a chat protocol.