Clojure Land – Discover open-source Clojure libraries and frameworks
clojure.land
clojure.land
Separately, I do wish Clojure would adopt a bit more of an opinionated way of doing things and coalesce around some solid core/common libraries that the official docs could point to. This year, Clojure didn't make it into the named languages list on the Stack Overflow developer survey (1.2% in 2024). It's clear that it's not all that popular, even though there's some commercial backing and a friendly community, and there just aren't enough developers to support a myriad of different ways of doing things. I do feel there needs to be a focus on getting beginners in, and that means helping them to do things easily.
- age + adoption over time
- number of bug issues (as confirmed by author) over time (is it going up or down?).
Clojure is clearly a niche language, but Stack Overflow is also not a place that Clojure developers typically go, so Clojure usage there is going to be under reported.
> I do wish Clojure would adopt a bit more of an opinionated way of doing things and coalesce around some solid core/common libraries that the official docs could point to.
Solid core/common libraries to do what?
It seems unclear to me why Clojure developers would not go to Stack Overflow, and especially unclear why they would avoid SO more than developers in other niche languages. When I learned Clojure, I spent a very long time on SO.
I suppose I’m just a little skeptical. I often hear similar sounding rationales - “oh don’t worry, <my favorite language/technology> is under-represented by the data”. Somehow every niche technology is underreported by the data! But to an outside observer, Clojure to me seems to be used very rarely in the types of engineering work I come in contact with, and 1% doesn’t seem that wrong to me.
That said, it's always worth checking the numbers, so I took a look at the 2024 State of Clojure Survey. Around 18% of those surveyed used Stack Overflow, while the 2024 Python Developers Survey had at least 43% of respondents using Stack Overflow.
Now, you might well say that even so Clojure is still a niche language - and I agree. But it may be the case that instead of a 1.3% share, Clojure has a 3% share - if we assume that the Python community's usage numbers are more typical.
The Python question is more broad: “Where do you typically learn about [python]?”
The Python question I'd say is more narrow, as it asks specifically about "new tools and technologies". What if I have a question about an tool I've been using for a while?
In any case, my point is not what market share Clojure actually has, but that there's reasonable doubt in using SO's developer survey as a basis for that answer. If a far smaller percentage of the Clojure community uses SO than is average for a language, then it's going to skew the results.
Yes, but a large percentage of people use SO without posting a question - e.g. an answer pops up in a google result.
I think for ehat I saw that Clojure is very clean and there is a clear way to do things but I keep finding people saying that Common Lisp interactivity is super good and CLOS amazing.
So my main question would be:
1. will this interactivity make a difference in my daily workflow? What I see is that clojure is anyway mostly stateless so fancy things like reload on the fly would not be very important...?
I tried Python with NiceGUI recently and I was impressed byt I want to try a more functional-like and possible hot-patching in production could be also a feature I would make use of from time to time, instead of sapwning full deployments.
Any feedback from experienced practitioners is welcome.
I would not want to write anything in CL today.
CLOS is beautiful, but what it really boils down to in practice are multimethods. Which exist in Clojure. And which I barely ever use, because my software is easier to understand and debug without multimethods. Also, CLOS assumes mutability, which is not something I want anymore.
Clojure has a fantastic concurrency story, runs on the JVM, so you get an actively developed platform with thousands of man-hours of invested work. You get great GC, and all the Java libraries.
Then there is ClojureScript, and most importantly, code sharing between the two. Most of my model (business logic) code is in cljc files and it's the same code for the server side and the client side.
When I had to go back and look at some of my old CL code, I found the mutability problematic.
Overall, there is still a warm spot in my heart for CL, but Clojure is quite simply better.
The other thing: can I patch something in production without redeploying in Clojure? I think both CL and Smalltalk have this live image feature. Is it possible to hot-reload a stateless function in Clojure without restarting the system?
I have a reason to ask for this since I think it will be handy at times for maintaining my own thing. Not a piece of software with 5 guys behind so it can make a difference in time invested.
Is this a regular way to deploy?
I mean, I saw there is Leinen or something like that for package management.
But once you run, you could still connect to an app that has been run in the usual way? Seems like a setup on top of it.
Or is is just independent?
You don't need it often, but when you do, it's invaluable. And the REPL is such a normal thing to use in Clojure, there's no reason not to do it.
You can fully reload everything in Clojure as well.
The only limitation is an existing object instance cannot hook into the reload cycle and upgrade itself at runtime. You need to re-create the instance.
But since Clojure is not object oriented, and if you have such objects they'll be from Java interrop, it's not something that you feel you'll be missing or need.
Yes you can hot patch Clojure in production, but modern deployment practices make that not really something people do, as you run multiple instances anyways, it's easier to swap full instances and be sure everything is in-sync with your repo and CI/CD environments.
What people do is more they use a production REPL to help root cause and debug.
Sure. But over the years I learned that I don't want to do that unless I'm debugging something, and I'd never do that in a production system anymore.
Like many other things in CL, they seem nice and shiny, and are sometimes beautifully designed (meta-object protocol!), but in practical day to day usage, especially with production systems, it's better to stick to simpler and more understandable tools, and predictable and repeatable deployments. Even if it's "your own thing" (I've been running my own SaaS for >10 years now). That's why I rarely use multimethods, I try not to be too smart and fancy with my code, I comment and document a lot, use ansible for deployments, and never patch production systems (e.g. every update goes through an ansible deployment).
By hot-patching you can make a mess of where things are probably.
Even if it is a bit more work, going through a more normal cycle lets you understand what is going on.
So for what I see from other comments and yours REPL is nice for interactive work and root cause debugging but hot-patching a production system, even if powerful, comes with its own set of problems.
The interactivity in Common Lisp is a bit better (navigate the stacktrace, debugger, object inspector etc) but the Clojure REPL is also very good and allow to change the code of your application live without recompiling the whole project. Clojure is a functional programming language, whereas CL is multi-paradigms so it's easier to deal with state in Clojure. The ecosystem of Clojure is much richer and you can always fallback on the endless Java ecosystem if something is missing.
In terms of asynchronous programming, not built-in to implementations (like, no green threads), we have
- https://github.com/orthecreedence/wookie - an asynchronous HTTP server
- https://github.com/fukamachi/woo - fast non-blocking HTTP server on top of libev.
- an actor-based task manager for Hunchentoot: https://github.com/mdbergmann/cl-tbnl-gserver-tmgr
see also https://github.com/CodyReichert/awesome-cl/#parallelism-and-... for promise libraries, async libraries, the actor library, an STM library, lparallel (run tasks in parallel, easy and often useful), bindings to other async tools.
Those libraries are active.
As such, Clojure has the benefit of Java ecosystem in libraries, and with something like Cursive you get close enough to the old Lisp Machine like development workflow.
For me it is the most interesting language on the JVM, when not using Java.
Common Lisp is interesting, from historical point of view, there are still features that modern languages lack, Allegro and LispWorks are still around, however unless it is for having fun, it is even more niche nowadays.
Lisp inspired languages like Julia, or Wolfran Alpha, might have much bigger userbase nowadays.
Personally my biggest issue with Python is the whole adoption drama regarding JIT tooling, there is PyPy as the black swan, however not like all major Lisp implementations with AOT/JIT tooling as standard. Clojure can have something like that via JVM JIT and GraalVM/OpenJ9.
(btw, ABCL has the benefit of Java libraries, for those interested)
Julia has its own issues (and isn't on par outside of scientific area).
Here are some more companies: https://github.com/azzamsa/awesome-lisp-companies/ (only the ones we know about)
https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...
Hence my niche remark, naturally there are a few using it, otherwise Allegro and Lispworks would have filled for bankruptcy already.
---
The thing in CL I miss most doing Clojure as my day job? CL's compiler. I like having a compiler tell me at compile time about the mistakes I've made. Bogus arguments. Unreachable code because of unhandled exceptions, and so on. CL saves me round after round of bugs that in clojure aren't found until you run the code. If you test well, it's found when testing, if you don't it's found in production. "Clojure compiler" almost demands air quotes.
CL's optional but oh-so-useful model of type declarations is also infinitely more useful (to me) than Clojure's use of "spec", and instrumentation that happens only at test time because of the cost. Depending on the OPTIMIZE declarations, other type defs are a floor wax and dessert topping. Want checks for argument types? Lower optimizations. Want most efficient machine code? High optimizations.
(decweb, 2023)
---
As a practitioner of both Common Lisp and Clojure, one of the things that draws me back to Common Lisp is its compiler and the many useful things it does when I C-c C-c a definition in my emacs buffer.
SBCL has many useful checks. I liked this one today (see image). It flagged the format line as unreachable (and deleted) code. It was correct, because the setf should have updated keys, not new-keys, and so keys would always be nil.
I really appreciate this savings in time, finding the bug when I write it, not when I eventually run it, perhaps much later.
Before the Clojure guys tell me they that linters or LSPs will catch this sort of thing, don't bother. Having to incorporate a bunch of additional tools into the toolchain is not a feature of the language, it's a burden. Clojure should step up their compiler game.
https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1...
It is true that a lot of things don't surface until you run the code, but the way you run code in Clojure is also different than other languages (but similar to CL) where this isn't that big of a problem.
Usually you evaluate the very code you're working on, as an isolated unit, after every change, with just a key stroke. Again, not different than CL, but very different than the rest of the Algol-like languages where you'd put the code you're editing under unit tests or worse, manually run the full program after each change.
I will say, all the warts in Clojure will be due to the constraints of the Java host and some of it leaking through. In that sense, Common Lisp has a better runtime that's really dedicated to itself and works in full harmony with the language. You get nicer compact binaries that run on a lower footprint.
But the flip side, is the Java host allows you to have access to everything you'd ever want, in terms of libraries, and you get access to things like virtual threads, native compilation, etc.
I believe the tooling in Clojure is more modern, there are now more polished plugins for all Editors, nice debuggers and so on. Not necessarily more features, just more modern feel.
The other big difference will be that Clojure is heavily functional and has few imperative constructs. No local mutable variables, no mutable loops, no standard global mutable variables, not object oriented, etc.
As for interactivity - I use a REPL daily with Clojure and it works just as you'd expect from a CL REPL. The only time you need to reload is if you add a new JAR to the classpath or occasionally when state gets really weird. There are reload facilities baked in to nREPL too.
For reference, I've used Clojure professionally for about a decade.
I'd suggest trying it out with Calva in VS Code.
In practice I find code in CL more difficult to follow than Clojure. Clojure macros like left-to-right reading, more generic functions and the maps withou confusion between quotes or multiple representations of maps and a few other more regularities in syntax plus the use of not only parenthesis make it more readable IMHO.
I also see that things like let need let* in CL if you want dependency order, etc.
Although the my biggest two reasons for liking CL are the condition system and the speed. While it's still slow as molasses compared to C, at least it's performance without any special tweaks is roughly acceptable for software which isn't user-facing.
Not sure about your information architecture. What is the difference between the web frameworks and web server abstraction tags?
This next question is more for the Clojure community. From https://clojure.land/?tags=Web%20Frameworks we see 34 web frameworks. That seems like a lot to me. Why is there so much "scratching your own itch" because you don't like ring?
Most problems solved by frameworks don't exist in Clojure. Most problems introduced by frameworks, therefore, don't exist in Clojure as well.
If a repo has been archived on GitHub then I do show a lock icon on the card. Some projects that have been completely abandoned have been hidden from the list but I've been reluctant to be the gatekeeper of what projects should be removed. I was kind of hoping that if a project owner considered their project dead then they would create a PR against the Clojure Land repo to remove or hide the project from the list.
Most of the tags came from the sections on https://www.clojure-toolbox.com/ and I'll admit they are a bit arbitrary and I would happily accept any help to make them better organized.
As always, PRs are welcome: https://github.com/brettatoms/clojure.land
The big difference between Clojure Land and the Clojure Toolbox is syncing with GitHub for things like description, stars, etc and search.
I also regularly follow the Clojurians Slack and /r/Clojure for project announcements. Of course PRs to help keep the project list up to date are always welcome.
From what I remember there is around 60k lines of Clojure itself and pretty much all files were edited like minimum 8 years ago, apart of main file with most of the function utilities.
Well... I like Clojure but I bet you will reconsider that sentiment if you scroll through https://github.com/clojure/clojure/blob/master/src/jvm/cloju... .
Which ironically is also why I wouldn’t touch clojure, because it’s the exact opposite of the message in his talk :)
Clojure is intertwined with the JVM. Stack traces are half clojure, half Java.
It is a perfect example of something which is “easy” but not “simple” according to his own definition.
I think the stack traces comment is fair, but not really about complecting.
Complecting would be say if your source code had to be compiled at the same time as the JVM’s source code, and you put your type definitions inside the memory manager’s code. Otherwise I don’t have to think about the JVM memory manager to write a program (generally speaking).
It’s not uncommon to see Java calls within clojure code.
With aot it generates Java classes, calls those stubs and dispatches.
Stack traces are half clojure, half Java.
It’s not just clojure, I feel the same with for example F# which makes calls to C# entities.
It might not be deal breaking for you. It’s also very pragmatic.
However imo it does clearly violate the principles from his talk. They are intertwined. Easy, not simple by his own definition.
Apart from that, very fun language though.