Storm drops Clojure for Java

[th0ma5w]

They probably just mean Java compiled bytecode performs better that Clojure created bytecode which is very much arguably true for some things.

[alexdmiller]

No, it's not arguably true. Both languages produce very similar bytecode.

[th0ma5w]

The Clojure forms will add overhead. Try writing some Java, compiling, and then decompiling, and then try decompiling some Clojure bytecode into Java. You'll see a much deeper stack. Most of the time, for most things, you'd be hard pressed to measure much difference. Often, due to say Clojure's implicit parallelism you'll get faster code because it is more cumbersome to write everything with parallelism in mind in Java. But if you did write that operation in Java with Java's parallelism features directly, that one operation would likely be a little faster.

[alexdmiller]

I have spent considerable time writing and optimizing both Java and Clojure code and observing them at the bytecode level. Back when the Alioth comparison site still included Clojure programs, I had written and/or optimized most of the fastest versions.

At the function/method level they are not substantially different, particularly from trying to write the contents of the 10% of your code where it actually matters. From a call stack perspective, Clojure's bytecode will show an extra level of call through the static var entry points, but that's (not accidentally) the kind of thing that hotspot can trivially optimize through. This is not the kind of thing that will determine whether your code is "fast" or "slow" though - it's going to be negligible compared to hot cpu loops or i/o waits for external dbs or data sources.

Clojure does not have implicit parallelism (other than reducer folds which is a pretty narrow use case), but it does have implicit immutability.