Almost certainly. You could go on: would it be faster written in C? In ASM? The question shouldn't be "can it be faster," but rather "is it fast enough?"
If you're worried about clojure not being fast enough where java is, you've always got the option of prototyping in clojure then dropping to java via clojure's interop where you have to.
A clojure program written in "canonical" style will usually be slower than the equivalent "canonical" java program (as long as canonical != enterprisey canonical), if only because canonical Clojure uses immutable datastructures and therefore spends quite a bit of time churning memory but Clojure lets you type-hint programs (to generate more type-tight bytecode, closer to what statically typed Java would provide), use Java mutable types and alongside compile-time metaprogramming that can be used to generate code which will likely be as efficient as tight Java code: http://www.learningclojure.com/2010/09/clojure-faster-than-m...
A bigger drawback to Clojure, in my experience, is that error messages are complete shit (most errors will yield stack traces to compiled bytecode, so you get java traces with a layer of obfuscation in that they're tracing the bytecode generated by clojure). The same issue exists when trying to improve performances, you get performance counters for java bytecode and have to match them to clojure code "by hand".
You may know this, but Clojure's immutable data structures don't spend near as much time churning memory as they would if they were implemented naively. Change one element of a sequence, and in your new sequence all the unchanged elements will reference the same memory locations they did before.
Sure, but you'll still need to reallocate all the tree path leading to the changed value, there's only so much immutable datastructures can share. And this does result in signifiant churn compared to an object/imperative system where most of the manipulations mutate existing objects (with very little allocations or deallocations comparatively).
I'm going wax poetically and say that there are a lot of things like GStreamer or the Javax stuff that's just going to be another library, and depending on what you're doing in Clojure it will run just the same. If you're designing something where your processing is happening with Clojure, it depends on how the JIT observes it and optimizes it, so mostly that stuff might be slower, but it also might be the same. Now, if you're really trying to push things, you could be doing all of it on the GPU, in which case it doesn't matter what language you use, your code on the CPU is just going to be uploading or otherwise managing the GPU work, so using C++ to do such things might not even matter given that the GLSL or whatever you're doing the GPU is compiled and running over there anyway. But as far as Clojure speed goes, the general feel I get is that it's generally slower than Java (for say a single thread, and especially interactively with the REPL) but still faster than C Python, but it also may surprise you with its transparent threading.
For most tasks, it's slower, but within the same order of magnitude. Performant processing of numeric data, however, requires quite a few ugly hacks (just like almost all functional languages).
Purely numeric operations in recent Clojure releases are unboxed, meaning primitive arithmetic executes the same way as it does in the JVM. There are several tricks for removing the overhead of dynamic function lookups, so function call overhead can be roughly the same as Java's. You also have access to Java arrays, including primitive arrays.
So, in theory you can write Java-in-Clojure and see similar performance between the two, as the just-in-time compiler will not be doing any more work for Clojure than for Java code. In practice, the code will not be as attractive as plain Clojure.
I was thinking of the same thing a few minutes ago, and for some tasks I think one is better off with Java (IMHO, I don't even do much Java - its just the C/Java style wins in some cases - I'm thinking of code with many array acesses).
But as a high-level language for high-level tasks, for gluing pieces of code and calling libraries all around and for dynamic chancing stuff like web programming, Clojure really shines.
Comments
What about speed. If one writes, for example, a video processing library in Clojure will it run slower than if it had been written in pure Java?
Almost certainly. You could go on: would it be faster written in C? In ASM? The question shouldn't be "can it be faster," but rather "is it fast enough?"
If you're worried about clojure not being fast enough where java is, you've always got the option of prototyping in clojure then dropping to java via clojure's interop where you have to.
A clojure program written in "canonical" style will usually be slower than the equivalent "canonical" java program (as long as canonical != enterprisey canonical), if only because canonical Clojure uses immutable datastructures and therefore spends quite a bit of time churning memory but Clojure lets you type-hint programs (to generate more type-tight bytecode, closer to what statically typed Java would provide), use Java mutable types and alongside compile-time metaprogramming that can be used to generate code which will likely be as efficient as tight Java code: http://www.learningclojure.com/2010/09/clojure-faster-than-m...
A bigger drawback to Clojure, in my experience, is that error messages are complete shit (most errors will yield stack traces to compiled bytecode, so you get java traces with a layer of obfuscation in that they're tracing the bytecode generated by clojure). The same issue exists when trying to improve performances, you get performance counters for java bytecode and have to match them to clojure code "by hand".
You may know this, but Clojure's immutable data structures don't spend near as much time churning memory as they would if they were implemented naively. Change one element of a sequence, and in your new sequence all the unchanged elements will reference the same memory locations they did before.
Sure, but you'll still need to reallocate all the tree path leading to the changed value, there's only so much immutable datastructures can share. And this does result in signifiant churn compared to an object/imperative system where most of the manipulations mutate existing objects (with very little allocations or deallocations comparatively).
I'm going wax poetically and say that there are a lot of things like GStreamer or the Javax stuff that's just going to be another library, and depending on what you're doing in Clojure it will run just the same. If you're designing something where your processing is happening with Clojure, it depends on how the JIT observes it and optimizes it, so mostly that stuff might be slower, but it also might be the same. Now, if you're really trying to push things, you could be doing all of it on the GPU, in which case it doesn't matter what language you use, your code on the CPU is just going to be uploading or otherwise managing the GPU work, so using C++ to do such things might not even matter given that the GLSL or whatever you're doing the GPU is compiled and running over there anyway. But as far as Clojure speed goes, the general feel I get is that it's generally slower than Java (for say a single thread, and especially interactively with the REPL) but still faster than C Python, but it also may surprise you with its transparent threading.
For most tasks, it's slower, but within the same order of magnitude. Performant processing of numeric data, however, requires quite a few ugly hacks (just like almost all functional languages).
Purely numeric operations in recent Clojure releases are unboxed, meaning primitive arithmetic executes the same way as it does in the JVM. There are several tricks for removing the overhead of dynamic function lookups, so function call overhead can be roughly the same as Java's. You also have access to Java arrays, including primitive arrays.
So, in theory you can write Java-in-Clojure and see similar performance between the two, as the just-in-time compiler will not be doing any more work for Clojure than for Java code. In practice, the code will not be as attractive as plain Clojure.
I was thinking of the same thing a few minutes ago, and for some tasks I think one is better off with Java (IMHO, I don't even do much Java - its just the C/Java style wins in some cases - I'm thinking of code with many array acesses).
But as a high-level language for high-level tasks, for gluing pieces of code and calling libraries all around and for dynamic chancing stuff like web programming, Clojure really shines.
Offtopic, but do you think anyone would consider writing video processing library in Java, is the technology that mature?