For Hadoop systems, using Cloudera's distribution can be very helpful with this, but existing Java libraries force Clojure developers to deal with the Java world of static compilation, command-line JAR execution, and configuration via XML. This serves as a major impediment to the kind of interactive and simple experience we expect with Clojure systems.
What is the benefit of using Clojure (as opposed to another Lisp) if the language's main USP, i.e. access to Java libraries, is turning out to be a problem? This is not a rhetorical question.
icey mostly answered your point, however the trick here is that without wrapping in libraries like this, you're simply getting the same experience as java to access the particular libs, which is still easier than accessing them from another lisp such as sbcl.
Easier than everyone else does not default to "stupid easy" all the time, at least not without work from people making wrapper libs like this.
OK, thanks for the explanation. I still wonder how good an idea it is to make such wrapper libraries instead of writing pure Lisp libraries in the first place, not in this particular case but as a general idea.
Certainly where it makes sense to invest the time writing pure clojure libraries (or mostly clojure with optimized java in a few key areas if you're running into spots you can't get as good a performance in pure clojure but java will) is preferred, but at least this gives you the option of using the non-fp styled libraries until such a time as someone writes them. Improved bootstrapping at it's finest.
YC doesn't take a board seat, so their options for forcing change in portfolio companies are pretty much limited to suing for breach of fiduciary responsibility.
What is the benefit of using Clojure (as opposed to another Lisp) if the language's main USP, i.e. access to Java libraries, is turning out to be a problem? This is not a rhetorical question.