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.
> This year, Clojure didn't make it into the named languages list on the Stack Overflow developer survey (1.2% in 2024).
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.
> 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.
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.
OTOH, 1% of a large group is still quite a lot. How many programmers are there in the world? Google says estimated 47 million. 1% of that is almost half a million people. If there are half a million Clojure programmers, Clojure is quite a successful technology! (Sadly, I doubt there are that many)...
Stack Overflow is one of those sites that benefit from a network effect. If there are few users of a particular technology on it, people are less likely to get questions answered and therefore less likely to interact with it again.
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.
I’m not sure if you can draw that conclusion. The clojure survey asks where users went to interact with other people who use Clojure. Who interacts with people on SO? I’m sure a vast majority just read the answer and move on. It makes sense that a Slack server would be the #1 result.
The Python question is more broad: “Where do you typically learn about [python]?”
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.
> Is it possible to hot-reload a stateless function in Clojure without restarting the system?
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).
You can expose a REPL socket from a running clojure instance in whatever environment you choose. Biff has this as a marketed feature, described on this page: https://biffweb.com/docs/reference/production/
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.
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.
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.
> CL saves me round after round of bugs that in clojure aren't found until you run the code
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.
Clojure is practically just as interactive, I don't feel that difference will be note worthy.
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.
I'd suggest Clojure simply because of the JVM. The JVM is unjustly maligned, and I will defend it to anyone at any time. Having access to the huge Java JAR ecosystem for integrations and libraries is a game changer compared to CL.
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.
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.
I would use CL without even thinking about it (it's just better)... but if you're going to be doing web you're going to find more articles and libraries for Clojure. So I'd recommend you go with that.
How are these libraries curated? I ask because Clojure Land includes Donkey https://clojure.land/?q=donkey which was abandoned a couple of years ago.
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?
I created Clojure Land. The idea is to be more comprehensive than curated and to be able to discover rather than recommend any particular project.
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.
Most of those are not really "frameworks" as such (with some exceptions, like Biff or Fulcro), but rather libraries, or curated collections of libraries. Most Clojure people tend to roll their own set of libraries, rather than use actual frameworks.
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.
Maybe not "elegant", but quite readable compiler impl. compared to what I have seen. And which (real world) compiler has an "elegant" implementation anyways.
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.
> This year, Clojure didn't make it into the named languages list on the Stack Overflow developer survey (1.2% in 2024).
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?
> 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.
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.
OTOH, 1% of a large group is still quite a lot. How many programmers are there in the world? Google says estimated 47 million. 1% of that is almost half a million people. If there are half a million Clojure programmers, Clojure is quite a successful technology! (Sadly, I doubt there are that many)...
Stack Overflow is one of those sites that benefit from a network effect. If there are few users of a particular technology on it, people are less likely to get questions answered and therefore less likely to interact with it again.
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.
I’m not sure if you can draw that conclusion. The clojure survey asks where users went to interact with other people who use Clojure. Who interacts with people on SO? I’m sure a vast majority just read the answer and move on. It makes sense that a Slack server would be the #1 result.
The Python question is more broad: “Where do you typically learn about [python]?”
I added an issue for this comment: https://github.com/brettatoms/clojure.land/issues/5
Metrics that would be valuable:
- age + adoption over time
- number of bug issues (as confirmed by author) over time (is it going up or down?).
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.
You can even share business logic between backend/frontend AND shell scripts via babashka!
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.
> Is it possible to hot-reload a stateless function in Clojure without restarting the system?
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).
You can expose a REPL socket from a running clojure instance in whatever environment you choose. Biff has this as a marketed feature, described on this page: https://biffweb.com/docs/reference/production/
Thanks for the link.
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?
It's regular, every production Clojure system has REPL access for devs.
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.
I don't think a game changes anything.
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.
The authors of The Art of Metaobject Protocol would disagree.
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.
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...
> CL saves me round after round of bugs that in clojure aren't found until you run the code
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.
Clojure is practically just as interactive, I don't feel that difference will be note worthy.
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.
I'd suggest Clojure simply because of the JVM. The JVM is unjustly maligned, and I will defend it to anyone at any time. Having access to the huge Java JAR ecosystem for integrations and libraries is a game changer compared to CL.
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.
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.
I would use CL without even thinking about it (it's just better)... but if you're going to be doing web you're going to find more articles and libraries for Clojure. So I'd recommend you go with that.
How are these libraries curated? I ask because Clojure Land includes Donkey https://clojure.land/?q=donkey which was abandoned a couple of years ago.
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?
I created Clojure Land. The idea is to be more comprehensive than curated and to be able to discover rather than recommend any particular project.
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
Those are not fully featured web frameworks, I guess they were just labeled by AI for this website. They are libraries specialized on one thing.
Most problems solved by frameworks don't exist in Clojure. Most problems introduced by frameworks, therefore, don't exist in Clojure as well.
Most of those are not really "frameworks" as such (with some exceptions, like Biff or Fulcro), but rather libraries, or curated collections of libraries. Most Clojure people tend to roll their own set of libraries, rather than use actual frameworks.
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.
> I was completely struck by how elegant its codebase is.
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... .
Maybe not "elegant", but quite readable compiler impl. compared to what I have seen. And which (real world) compiler has an "elegant" implementation anyways.
I love Rich Hickey’s talk “simple made easy”
Which ironically is also why I wouldn’t touch clojure, because it’s the exact opposite of the message in his talk :)
How so?
Simple made easy talks about things which are “simple” as in not intertwined, vs “easy” (it works, but is tangled or intertwined).
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.