Clojure Land – Discover open-source Clojure libraries and frameworks
12 comments
·October 26, 2025germandiago
As a person that is doubting for a backend project (web) between Clojure and Common Lisp, what would you recommend and why?
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.
jwr
Ex-Common-Lisper here. I spent many years writing software in CL, then discovered Clojure, and have been writing and maintaining a large production system in Clojure/ClojureScript for 10 years now.
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.
germandiago
Yes, my gut feeling tells me that sticking to functional + modern platform is safer. Having structure can also be seen as an advantage IMHO.
Kototama
If it's for a hobby project it can be fun to work with Common Lisp and see all the good things such an old language still has to offer and where it's still superior to more modern languages. You also don't need to deal with the JVM and will have nice stacktraces (Clojure stacktraces are a mix of Java land and Clojure land). However the ecosystem is very thin so you might have to implement more stuff yourself or being blocked on something (no asynchronous programming for example if you need a very high performance web application). It's not rare to search for a library and find that the last edit was 7 years ago. Maybe it works, maybe it does not, but it surely is not maintained.
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.
vindarel
I'll invite to explore the CL ecosystem starting with https://github.com/CodyReichert/awesome-cl/ (it might be larger than one thinks)
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.
pjmlp
Unfortunately Lisp will never go beyond being a niche language in modern times.
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.
vindarel
It's niche but used enough in the industry to give us tools like Coalton (https://github.com/coalton-lang/coalton/), used enough by hobbyists to give us nice new libraries (new TUI library: https://github.com/atgreen/cl-tuition/blob/master/examples/R...) and exceptionally good and fast open-source compilers (SBCL) (with a good bus factor and contributors from the industry, like Google), it has enough libraries to allow us to ship software to clients (web clients, web servers, web UIs (webview, webui), SQL libraries, etc). It's niche but the motivated developer can publish a game on Steam (Kandria).
(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).
pjmlp
I can also quote about 5 companies using Common Lisp in production, and there are enough paying customers to keep Allegro Common Lisp and Lispworks in business, yet that doesn't mean we are going back to the same amount of market presence as before the AI Winter event.
vindarel
Another big difference, given feedback of people who used both languages, is the CL compiler.
---
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...
lincpa
[dead]
There's an existing site for this: https://www.clojure-toolbox.com/