Hacker News Reader

Comment by tgerdin | Hacker News Reader

Looks like a pretty solid release, very happy that Clojure is still going strong!

Is it going strong? I'm evaluating it for a new project. I'm considering it together with Clara[0]. However, it does give a vibe that it's not as mainstream as it was before and that the ecosystem is more sparse than what is once was.

I'm not trying to troll. I want to choose it. It seems like a good engineering decision to me, but if it's nosediving in popularity and contributors, this might bite me back in the near future.

[0] https://www.clara-rules.org/

Clojure's slow, deliberate development pace confuses people. The core team takes backwards compatibility very seriously. What you see with each new Clojure release is generally improved performance, better Java interop, and a smattering of new features. This is doubly true for 1.12 which is doing quite a bit of invisible work to make interop considerably better.

So what you don't see is a constant flux of "innovation" followed by a community having to adapt to those innovations. People pull Clojure examples out of books that are 12 or more years old and they still run.

I think there's some very exciting things in the Clojure space, such as Clerk (https://github.com/nextjournal/clerk) for live notebooks, and Babashka (https://github.com/borkdude/babashka) for amazing (and amazingly fast) scripting.

I guess that the GP didn't talk about the language itself, but the users. For me it looks like Scala and Clojure had lost many of its users because of Kotlin and newer Java versions. Generally I see a decline in the usage of functional languages since their heyday in the 2010s. I guess that's because imperative languages either get "functional features" or are "functional enough" - new ones like Rust or Swift.

Clojure is more lindy than Scala.

If someone tells you their project is written in Scala, Golang, Groovy, Coffeescript it almost dates the project doesn't it? Not so much in Clojure.

It's niche but I can bet it's still going to be there 10 years from now, going at least as strongly as now.

I'm not so sure. I wish it were as you say but there are currently 5600 job postings mentioning Scala on LinkedIn in the USA, vs 82 that mention Clojure. 82! In the entire USA. So even in its state of relative decline, Scala might be about 70 times as used in industry as Clojure is.

Even as I flip through the 7 postings mentioning Clojure in all of Canada, only 4 of them seem to indicate the job itself makes use of the language (rather than mentioning it just as an example language as in "* Fluency in one or more languages like Ruby, Clojure, Scala, ReactJS, JavaScript, TypeScript, Java, Python - Deep understanding of internet protocols and standards.")

What Clojure dev uses LinkedIn to find jobs?

I certainly wouldn't.

From the last view developer surveys I've paid attention to it didn't seem like Clojure was growing much but it's definitely still large enough of an ecosystem to be a valid choice. So, depends on your definition of 'going strong'. On its merits it's definitely still a great choice, I never really thought of it as particularly mainstream.

I found myself frustrated a lot when I used it two years ago. A lot of abandoned libraries. There's not a huge ecosystem around it compared to golang and other popular languages, but there's probably enough that it's a viable option if you really want to work with the language.

I think there is this misconception that lack of activity on libraries indicates they aren't worth using. But I strongly believe a lot of libraries are just feature complete and bug-free enough to leave them be. The syntax of the language changes so minimally that libraries don't have to change at all after updates. This isn't Javascript where everyone keeps tweaking things over and over again.

I agree, solid working libraries often don’t need frequent updates. Sort of Common Lisp: a lot of old very stable code that just works fine.

Also the whole/part of the point of being hosted on the JVM is if there isn't a clojure lib for something you can just use a Java lib.

The problem this creates is that as a potential consumer I can't tell the difference between "effectively done" and "abandoned, half-done, and about to waste a lot of my time".

I don't see an easy answer to this because having "done" be an available state is extremely attractive, and forcing extra work on the author would be the wrong thing to do.

Well, picking libraries shouldn't be done willy nilly by looking at the stars in a github repo or that they contributed 5 minutes ago. There are many curated resources that help pick libraries. Here is a great one: https://www.clojure-toolbox.com/

Something I've found to be more true of Clojure libraries than those in most languages is that they can be finished. Once the code does the thing it set out to do, there's often no need to do anything else. The language is unlikely to break compatibility, and idiomatic code tends to be mostly functional with very clean interfaces.

The one example I can think of where that's emphatically not true is clojure-android, which was tightly coupled to the Android SDK and did not remain usable after the main developer moved on. The Android SDK does not share the aforementioned traits.

I find this to be the case in Lispy languages in general (CL, Scheme, Clojure..); I go looking for a library that does X, only to find that someone wrote one more than a decade ago. It looks weird coming from more fast paced languages, but Lisp maintainers tend to their libraries carefully and might tweak them over the years but they're mostly complete already.

Exactly.

Find a random node package that was last changed 4 years ago and it might as well be toxic waste.

Find a clj lib with the same stats and it's probably going to work smoothly.

> I found myself frustrated a lot when I used it two years ago.

Sad to hear about your experience.

> A lot of abandoned libraries. There's not a huge ecosystem around it compared to golang

I found it to be the opposite. In Clojure you have Clojurists Together: https://www.clojuriststogether.org which funds people to work on Open Source libraries. And more importantly there is Clojure Commons: https://github.com/clj-commons which takes popular Clojure libraries, that are no longer being supported and carries on looking after them.

When I found popular Go libraries that have been abandoned, I asked in the Go community, if there are such initiatives, especially seeing how Google is behind Go. When people didn't understand what I meant, I pointed them at the examples above, from Clojure. To which their response was "TIL, Clojure, never heard of it before! No, we don't have such initiatives in Go."

Maybe the initiatives from Clojure Commons & Clojurists Together need more visibility for the newcomers to Clojure?

I know a lot of people are making the case libraries are just finished not abandoned, but your feelings are valid. It’s like investing in a really low yield but dependable bond, when everyone around you is making huge gains on tech stocks. I like libraries that get more featureful over time, but sometimes you watch your friends go broke.

There are opportunity costs too, maybe you can say Spec is perfectly fine but you’d be forgiven for having mixed feelings with a massive codebase built on that in a world where many have moved to Malli or elsewhere.

But let’s also be honest, loads of promising Clojure libraries do get abandoned, not finished. ClojureQL was a brilliant, composable approach to writing SQL queries but never reached its potential and was left in a fairly buggy state. I’m probably four or five Clojure data access libraries on from that in my career now. Om was highly influential but good luck if you made an investment in that. Incanter could have been enormous but failed to reach critical mass and you’d be crazy to pick it up now. There’s ‘core’ stuff like core.logic that feels like a decade old unoptimised proof of concept that didn’t follow up any of the interesting paths it laid down. Heck, I’ve even got code that relies on libraries from Chris Zheng, who quit the scene after getting a deserved dressing down from Rich Hickey after complaining about the Clojure development process.

None of this is a moral failing on the Clojure community, and there’s no reason to be defensive about it. It’s a small ecosystem and it’s very hard to build critical mass. Clojure people often have magpie brains that pull them to work on new things. You’ve got to judge it for yourself.

This is my favourite example of a not-abandoned library: https://github.com/candera/causatum?tab=readme-ov-file#liven...

"As of this writing (25-Sep-2014) I consider this library alive and well"

... "Update 2017-Oct-16: Still true. :)"

This library has been done-done for a decade now. I used it last week.

I'd categorize Clojure as stable but niche. It's not nosediving in popularity, but I don't think it's growing by leaps and bounds either. Many libraries are also stable, in the sense that they are finished - sometimes people will see no activity on a GitHub project and assume it is dead when in reality it's just done. Clojure libraries tend to be very small and focused, and often no Clojure wrapper is needed at all due to the ease of Java interop.

I love Clojure, and it's been great for me and all the professional teams I've worked on that use it.

What you’re seeing sounds familiar but definitely not new. I’ve used Clojure professionally for 15 years and at no point in that time have you been guaranteed critical mass around any library or framework. Clojure has always been a small ecosystem of high variance people and projects. You get things like Rama and Electric which are bold reimaginings of what systems could look like, but you also get a lot of short lived, burnt out efforts that fizzled.

The good news is nothing really _breaks_ ever, and you have access to the entire JVM ecosystem if you want it (many Clojure people find Java interop icky which I personally find moronic).

I don’t do much Clojure anymore (I wish I did!) but agreed on all points. The JVM interop is such a huge, huge advantage that it’s hard to express to people who aren’t used it.

Electric looks outstanding. It seems like the sort of thing that would take some time to spread but once it does and people take the time to learn it it could be huge.

Ironically, Clojure seems to be the only guest language on the JVM where the community is welcoming of the platform that makes their existence possible in first place.

Similarly to how Groovy used to be, but I am not counting it as it seems only to be around to power Gradle and little else.

Scala and Kotlin folks speak too much about replacing Java, yet I am yet to see their native variants match JVM in any form or fashion.

Even if we take Android into consideration, Google was forced to update their Java support, as means to keep Java libraries ecosystem available for Android developers and their beloved Kotlin.

The really nice thing about Clojure is it runs on the JVM.

The entire ecosystem could die tomorrow, and you can still compile new Clojure code for any system that supports Java in the future.

Reagent is the clojurescript wrapper to react Reagent has the same API and the same best practices since 2014 Meanwhile, react changed from creactClass to extend Class. From classes to function components.

Many clojure libraries are simply done. There is no reason to commit everyday to a project.

Its dead in the water. Sure, some people like it for their private projects and I'm sure there are some commercial products but I wouldn't touch it. I dont particularly like Scala either but at least it has Spark which means it'll be around for decades.

Scala for spark is in decline too - people prefer the Python bindings for some reason.

I'd also look at

https://github.com/oakes/odoyle-rules/

I think the userbase is slowly shrinking, but I'd personally use Clojure even if all Clojure developers disappeared tomorrow. It's not built on shifting sand as the JVM is stable. If you need really niche/cutting edge stuff you're probably going to need to dip into Java or JS interop anyway

Thanks for the link! I’m not the parent poster, but I was thinking of using Clara Rules for prototyping a game idea and to get some experience with rule engines. I don’t think that truth maintenance (which is handled by Clara and not O’Doyle) is important for my use case, and O’Doyle looks simpler to pick up.

NuBank[0] mainly use clojure for most of their software, and NuBank is a big yet quickly growing company.

[0]: https://en.wikipedia.org/wiki/Nubank

There's another Clojure rules library worth considering. It has a section in the README about why you might prefer it to Clara.

https://github.com/oakes/odoyle-rules

Reply on news.ycombinator.com