It would be helpful to see some additional stats, like the number of issues and the last update. Of course, these are only heuristics, but they are still helpful to see. It's often pointed out that one of the great things about Clojure is that the libraries generally don't need updating that often because the language is pretty stable. However, quite often I do find that libraries have a number of long open issues or depend on outdated, sometimes insecure, versions of Java libraries. I realise that I'm complaining about free code, so 'fork it and contribute' is a valid response, but at the risk of further fragmentation and yet another library that exists for just a short period.
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.
I’m the creator of Clojure Land. I did base the original project list on the Clojure Toolbox and give full credit in the repo’s README.md.
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.
When I discovered Clojure, apart from the functional language properties and Java integration it brings with it, I was completely struck by how elegant its codebase is.
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.
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...?
What other diffeerence would you say make a big experience difference.
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.
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.
It would be correct if I said that for something like a game CL with its full hot reloading would be an advantage but for web-like where things can be made mostly stateless would not make a difference (namely, in practical terms I do not need to restart things)
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.
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.
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.
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).
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.
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.
It would be helpful to see some additional stats, like the number of issues and the last update. Of course, these are only heuristics, but they are still helpful to see. It's often pointed out that one of the great things about Clojure is that the libraries generally don't need updating that often because the language is pretty stable. However, quite often I do find that libraries have a number of long open issues or depend on outdated, sometimes insecure, versions of Java libraries. I realise that I'm complaining about free code, so 'fork it and contribute' is a valid response, but at the risk of further fragmentation and yet another library that exists for just a short period.
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.
I added an issue for this comment: https://github.com/brettatoms/clojure.land/issues/5
There's an existing site for this: https://www.clojure-toolbox.com/
I’m the creator of Clojure Land. I did base the original project list on the Clojure Toolbox and give full credit in the repo’s README.md.
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.
Also, here’s the project repo: https://github.com/brettatoms/clojure.land
When I discovered Clojure, apart from the functional language properties and Java integration it brings with it, I was completely struck by how elegant its codebase is.
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.
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:
What other diffeerence would you say make a big experience difference.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.
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.
It would be correct if I said that for something like a game CL with its full hot reloading would be an advantage but for web-like where things can be made mostly stateless would not make a difference (namely, in practical terms I do not need to restart things)
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.
Yes, my gut feeling tells me that sticking to functional + modern platform is safer. Having structure can also be seen as an advantage IMHO.
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.
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.
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.
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).
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.
no that doesn't mean we are going back to the same market presence, indeed. Do we have or will we have a useful-enough market presence?
Here are some more companies: https://github.com/azzamsa/awesome-lisp-companies/ (only the ones we know about)
Now compare that list to the amount of companies using the top languages listed here,
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.
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...