On Performance and Java Interoperability: Clojure vs. Scala

JavaPerformanceScalaClojureJvm

Java Problem Overview


I have already read various accounts of Clojure vs. Scala and while I realize that both have their place. There are a few considerations that I haven't acquired a complete explanation on when it comes to comparing both Clojure with Scala:

1.) Which of the two languages is generally faster? I realize that this will vary from one language feature to another but an general assessment of performance would be helpful. For example: I know that Python dictionaries are really fast. But as a whole, it is a much slower language than Java. I don't want to go with Clojure and run into this problem down the road.

2.) How is interoperability with Java? All I have read so far is that Scala has native collections types that make it a bit clumsy to integrate with a large Java code-base, whereas Clojure follows a simple Iterable/Iterator-centric way to inter-operate with Java classes. Any more thoughts/details on this?

Ultimately, if it is a close enough draw between clojure and scala, I might try them both. One thing about Clojure is the language seems very simple. But then again, Scala has a very flexible type system. But, I know that Scala is fast (based on multiple personal accounts). So, if Clojure is significantly slower: I'd like to know sooner rather than later.

Java Solutions


Solution 1 - Java

I think either language will be fast enough for you. When comparing Python and Java, it seems a bit unreasonable to blame the language for the speed difference. Java is compiled JIT (except on mobile devices*) whereas Python is interpreted. Just because both use a bytecode does not mean the implementations will have even remotely comparable performance. But both Scala and Clojure are JVM languages so they should have similar performance.

Scala has a few implementation advantages over Clojure and I would expect somewhat higher performance. Although Scala's static typing would normally translate into a speed advantage over Clojure's duck typing, Clojure does support type hinting which can speed up code considerably. Possibly, ordinary Scala is faster than ordinary Clojure, but you only need to optimize the bottlenecks. Most of a program's run time is generated by a small amount of the actual code.

Regarding interop w/ Java, Scala is closer to Java but I'm sure both languages interoperate well. In Programming Clojure Stuart Halloway writes: "[you can access] anything you could reach from Java code.".

And since Scala author Martin Odersky wrote Sun's Java compiler, I kinda think no balls have been dropped on the Scala side, either. :-)

You would be hard-pressed to pick two better languages, though I like Ruby also. Why are you worried about which one to try? Why not try them both? Scala is more likely to be "the next Java", while it's hard to imagine that Lisp will finally take off after not doing so for over 50 years. But it's clear that Lisp is on its own unique level of abstraction, and Clojure is fairly simple, so Scala + Clojure won't be that much harder than just (the rather complex) Scala and I'm sure you will be glad you did it.

And for that matter they interoperate...

* dalvik (android's JVM) got a JIT compiler in 2.2 version in 2010

Solution 2 - Java

With the present JVM Scala has an advantage on the account of being statically typed, as JVM support for dynamic typing -- reflection -- is slow. In fact, one Scala feature which must be implemented through the same techniques, structural types, is often warned against for this very reason.

Also, Scala accepts mutable objects just fine, and some algorithms are just faster to implement with mutability.

As both Scala and Java are essentially class-based languages, they interoperate more easily. Or, perhaps, more seamlessly. A Java class is a class to Scala, and a Scala class is a class to Java. Problems might arise when it comes to Scala's singletons or Java's static members, particularly when there's a framework involved expecting things to work in a certain way.

So I'd go with Scala on both these accounts. Clojure is, in many ways, a better language, and it certainly has very interesting features not present (so far) on Scala, but you reap such benefits by going fully functional. If you intend to do that, then Clojure is very likely better. If you don't, then you should probably stay with Scala.

Solution 3 - Java

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.

In my opinion, the features and concepts of a language (functional, OO, ...) are much more important criteria for choosing a language than the performance (of a particular implementation of that language) - altough I understand that you don't want to get trapped into a language for which there is no well-performing implementation available.

I'd go for Scala, because it is object oriented but also allows you to learn functional programming (if you're interested in that). On the other hand, if you don't care about OO and you want to learn "pure" functional programming, try Clojure.

Solution 4 - Java

  1. Idiomatic Scala is faster than idiomatic Clojure, and will remain so.
  2. Both Scala and Clojure sit easily on top of Java. Neither sits well underneath it.

If your code is time-critical or space-critical throughout, stick to Java. But it isn't, even if you think it is.

The Computer Language Benchmark Game sheds little light on Clojure's true resource costs. No Clojure data structures are employed. Functional and sequence abstractions do not appear.

Clojure may appear to be simple. It isn't, but it is expressive. It may run five times slower than Java, but the source is five times smaller (YMMV). For most of most applications, this is a big win. But for some, and for some parts of many others, it's a devastating loss.

With experience of the Clojure language, I believe it is possible to tell in advance whether your problem will cleave cleanly into a part that can be succinctly and adequately (in performance terms) expressed in Clojure and a part that needs doing in Java.

  • You can go for Scala lite: writing Java idioms in Scala. You'll gain some brevity, a syntax that's easier on the eye, and a coherent albeit complex type system.
  • There is no such thing as Clojure lite: writing Java idioms in Clojure is utterly pointless. All you'll get is slow Java that's hard to understand because it cuts across the grain of the idioms used to express it.

Scala has been said to be Java done right. Clojure is nothing like Java. You might say that it is Lisp done right - a bold, some would say preposterous, claim - which may turn out to be true.

Solution 5 - Java

The stats produced by the "Computer Language Benchmark Game" are about the best you're probably going to find.

They are in-depth and you can compare many languages. The problem is that they don't cover Clojure :(

That said, it's pretty easy to submit anything--it's all open source.

The stats do say that Scala is pretty damn quick.

Solution 6 - Java

On interoperability, I can't speak for Clojure, but I would expect it to be in a similar situation as Scala.

It is trivially easy to call Java from Scala.

It is easy to call Scala from Java as long as you conform your external API to the common points between Scala and Java. For example, a Scala object is used in some ways like static methods in Java, but it's not the same thing. Scala classes may compile to a number of classes with names that look funny in Java.

You will not want to mix and match much. Building component in Scala or Clojure that uses lots of Java libraries is very feasible. You can of course call into this component from Java, but what you are not going to want to do is try to consume a Scala API intended for use by Scala programs from Java.

SVN claims to be "CVS done right". In my view, Scala is Java done right.

Solution 7 - Java

The November 2010 issue of PragPub discusses Clojure-Java interoperability. Calling Java methods is straightforward, but extending Java classes/interfaces is quite different.

Scala on the other hand is much closer to Java. Scala-Java interoperability is elaborated at http://www.codecommit.com/blog/java/interop-between-java-and-scala

Calling Java code and extending Java classes/interfaces works the same way as calling Scala code. Some pain points might be some edge cases of dealing with Java's generics, because Scala's type system is much stronger than Java's. Creating getters and setters following the Java Bean convention requires an annotation.

Calling Scala from Java is most of the time straightforward, but for example Scala's companion objects requires knowing how they are compiled to bytecode. Also using traits with non-abstract methods from Java should be complicated, and calling methods with special characters would require knowing how they are encoded in the bytecode.

Solution 8 - Java

It's now (as of May 2010) worth loking at the latest 1.2 branch of Clojure - this includes a lot of additional support for primitive types and static typing (through various type hints and protocols).

My understanding is that you can use these features when you need it to get speed equivalent to writing exactly the same code in pure Java.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionRyan DelucchiView Question on Stackoverflow
Solution 1 - JavaDigitalRossView Answer on Stackoverflow
Solution 2 - JavaDaniel C. SobralView Answer on Stackoverflow
Solution 3 - JavaJesperView Answer on Stackoverflow
Solution 4 - JavaThumbnailView Answer on Stackoverflow
Solution 5 - JavaBill KView Answer on Stackoverflow
Solution 6 - JavaKevin PetersonView Answer on Stackoverflow
Solution 7 - JavaEsko LuontolaView Answer on Stackoverflow
Solution 8 - JavamikeraView Answer on Stackoverflow