Hacker News Reader

Comment by tombert | Hacker News Reader

> in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits

I cannot speak for anyone else, but as someone who writes a lot of Clojure (not much ClojureScript), I actually tend-towards the most-maintained libraries, and that usually just means Java. Personally, I think Clojure is a "better Java than Java", and I've never had a huge problem calling into the Java versions of libraries.

For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries. I absolutely hate Java as a language, but personally as an engineer it's hard to dispute that Java libraries tend to get a lot of money spent on them, and it feels silly to completely ignore that in some pursuit of "purity".

This actually seems to be more-or-less the ethos of the Clojure engineers where I work, but maybe my situation an outlier.

View on HN

I really really enjoy Clojure and think its success will only grow.

The (excellent) Java interop is a major strength. I’d argue it’s also a double edged sword: Java libraries tend to be very mature and capable, and Clojure programmers, especially the senior ones, tend to be very comfortable in Java, so often the native libraries just don’t get written.

I went to look for a CSS selector library the other day, the accepted solution seems to be to just call into Jsoup. I did find a native xpath library but it was such a thin wrapper around Java stuff that I ended up needing to learn those APIs to get something done the wrapper author hadn’t considered.

The thing about relying on Java libraries is the users, who came because they like lisp and Clojure, spend an inordinate amount of time trying to wrap their heads around Java apis (if they don’t know them already). Which is not fun.

> For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries.

As someone who is trying to decide how to interop Clojure + ZeroMQ, do you have any pointers for working with JeroMQ within Clojure?

Yesterday, I was browsing/evaluating the Clojure libraries for ZeroMQ, and all them haven't seen git pushes in the last three years and have between 10 and 120 stars on GitHub -- but JeroMQ has recent activity and >1.8k stars, so I'd like to stick with that for sake of support/documentation/etc.

(Caveat: ... not that GitHub stars are the best metric for quality... but they're not a terrible one...)

Honestly, I just went through all the JeroMQ examples ported from the guide [0], and translated them to Clojure. I added no dependencies outside of JeroMQ, and tried to port them in an as-idiomatic-as-possible way. It actually wasn't too hard once I wrapped my head around it, and it took me about 6-8 hours in total (spread over the course of a week or so), so not a huge time sink. This also had the (unintended) benefit of me getting pretty good with ZeroMQ (and networking patterns in general), so I think that time investment paid for itself several fold.

I definitely think there needs to be a better messaging with the library support in Clojure; as it stands, a Clojure newbie might (very reasonably) look up "clojure zeromq" on Google, get a crappy, unmaintained library, and dismiss the language as having "bad library support", when in reality most of the Clojure veterans that I work with do the same thing that I do: when the Clojure libraries are bad, just use the Java ones.

There are exceptions to this in rare cases; I haven't done a ton of ClojureScript, but the bit I have, I genuinely really liked the Re-frame framework. I'm not a frontend guy, so I'm speaking largely out of my ass, but I found it to be a lot more pleasant then vanilla React.

[0]https://github.com/zeromq/jeromq/tree/master/src/test/java/g...

Reply on news.ycombinator.com