[pinchhit]

As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown.

You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something, and in practice you only have 1 smart person focused on your business.

As the other 9 continue to reinvent wheels, the nature of clojure being small relative to other open-source communities means that eventually your shiny new clojure tools get replaced by better community offerings, except you don't have the bandwidth to switch over and start using them.

Overall, velocity would be improved if you had hired 1 super smart engineer and 9 mediocre ones.

It's important to note here that while technically clojure can interoperate with java or javascript, in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. This effect is 10 times worse for clojurescript in the browser, although it's pretty bad for clojure targeting the JVM as well.

[tombert]

> 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.

[mapgrep]

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.

[ryanmjacobs]

> 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...)

[tombert]

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...

[fulafel]

Interesting, my experience in Clojure projects has been completely the opposite re your caveat: very pragmatic & get-things-done developers, and everyone-works-on-everything or nearly so style of working.

The most used Clojure libs are well maintained and solid IME. Of course there are a lot of inactive ones too, it's natural especially as Clojure is not a young language anymore.

[beders]

> poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly.

Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years.

What am I not seeing here?

[Scarbutt]

Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...

[fulafel]

The gains from the advanced optimizations mode under discussion there are nice and the setup is known to be a little finicky wrt dependencies. But it's opt in and rarely necessary.

[Scarbutt]

Unless you want to ship a 5MB browser bundle for a 'hello world', advanced compilation is not necessary, is obligatory.

[fulafel]

It's like 200 kB gzipped for hello world with simple optimizations.

When you use webpack, you can use that ecosystem of space optimizers too.

[aeoleonn]

At a contract job, I had to use ReAgent, ClojureScript's "this compiles into ReactJS" framework. Wow, what a pain-- all I could think is "Why don't we just use Reactjs?".

Clojure itself is decent. But as you mention-- "n practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly.'

That is indeed the problem I saw.

[simongray]

There are some questionable Clojure libraries, but Reagent is fantastic. Much nicer and simpler than React. For years it's been completely hegemonic in the ClojureScript space and it's definitely not going anywhere.

I've done React+Redux and it was a much worse experience than Reagent, which deliberately builds on Clojure's native immutability-friendly state management solution (atoms) and is based entirely around functions.

[jb1991]

What did you find painful about Reagent? I used the first version of Om for many years, which by now is definitely old and outdated, but it still was much more enjoyable and productive than directly using ReactJS. Reagent is a small, simple library that makes interacting with React quite straightforward as well, so I'm curious your pain points.

[aeoleonn]

The lazy bastard that I am, I already knew ReactJS. ClojureScript's stack traces suck. I just didn't want to have to implement stuff in ClojureScript when I could write it in a language I was more familiar with. ReAgent/ClojureScript just seemed hacky. I don't remember specifics as it was almost 2 years ago.

[pinchhit]

I have noticed that our developers coming from javascript pretty much exclusively feel that way (and tend to write sharper UIs.) The ones who come from the JVM and feel more emboldened to write more frontend code thanks to reagent write UIs that don't satisfy product requirements, but are very happy with reagent.

Not that devs coming from the JVM can't contribute! But there is some eyerolling from the devs coming from javascript when the primarily backend devs throw together a too-simple UI and wonder why everybody doesn't use reagent exclusively.

[prepor]

> Why don't we just use Reactjs?

"Dealing with immutable data in JavaScript is more difficult than in languages designed for it, like Clojure. "

From React's docs.

[alexeiz]

> 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something

Hey, that's me! After 20 years I learnt to let go and start caring about the business a little bit more than about the code plumbing.