[anonjon]

I think that it is difficult to know what constitutes a 'fair benchmark' for Clojure. Are we talking unadorned Clojure, Clojure with type annotations, Clojure using Java structures, or Clojure calling Java code? Clojure calling Java is as fast as Java (obviously). And what if I had 60 cores as opposed to just 4 or 8? Parallel naive Clojure would then be 4 times faster than the Java version. The parallel clever version in Clojure would most likely be much faster. And barring a breakthrough in quantum computing, you will some day have 60+ CPUs in your desktop.

Most of the benchmarks that I have seen that were legitimately 10x the time of Java were using unadorned Clojure on Clojure data structures... of course it is slower, the machine is doing a lot more for you.

And it is well and good that this is the case, because the purpose of Clojure is not to make that tight loop really fast; it is to get the logic of your program correct and avoid a lot of the subtle bugs that can happen. Concurrency has many advantages above and beyond parallelism.

As far as getting along without macros and lazy evaluation and heterogeneous immutable data structures, I will say that for a long time we got along 'just fine' without garbage collection; but now it is a feature of a large subset of languages (to the extent that Google has now added it to C).

[sreque]

This link is fairly illuminating of clojure's performance: http://gnuvince.wordpress.com/2009/05/11/clojure-performance.... A guy writes some Java code, writes some clojure code, and notices that the clojure code is ridiculously slower, about 100 times or more, even slower than his Python implementation! After some serious profiling and help from the clojure mailing list he gets it down to 6 times as slow. What if he decided to try to optimize the Java code even further? He might be even be able to push the gap to 10x.

As far as all computers having 60 cores some day, if your clojure code is 10 times slower than my Java code, I only have to use 6 of my 60 cores to be as fast as your clojure program, which would be bringing my 60 core system to it's knees. It's not like you can't parallelize in Java! It's going to be decades indeed before a 5-10x reduction in performance doesn't matter because of ubiquitous core availability.

[anonjon]

I think you are missing my main point. If the java code is faster, and you really need speed, just call the optimized java code.

If you take seriously the rule that most programs spend 90% of their cycles in a limited number of subroutines (and you rewrite those few locations in Java), you should get speed pretty much equivalent to the Java code.

(Of course, in benchmarks this fails, because benchmarks generally measure the places that i might rewrite).

And then you use Clojure for the tricky and error-prone flow control types of jobs. I hate it when people turn this into a 'Clojure vs. Java' debate. It isn't like that.

It is about Clojure and Java. And I think Clojure and Java wins hands down over the Java only approach (at least for a lot of applications).

[sreque]

Sorry if I started sounding like I was making this a Java vs. Clojure approach. I wasn't. My original point is that there are no compelling reasons for me to use a language like Clojure over a language like Ruby. Clojure's biggest selling point, having high-level primitives to parallelize with, is meaningless to me because it is so slow, and it's other selling point, increased productivity, doesn't doesn't mean much to me either because I feel like I can be just as productive in Ruby or Python. I can make those my glue languages. I was originally responding to a post by someone asking "Why Clojure over Ruby?"

By the way, I think combining multiple languages on the JVM is a great idea and it was what prompted me to investigate Clojure in the first place.