[HN Gopher] Clojure Land - Discover open-source Clojure librarie...
       ___________________________________________________________________
        
       Clojure Land - Discover open-source Clojure libraries and
       frameworks
        
       Author : TheWiggles
       Score  : 152 points
       Date   : 2025-10-26 08:15 UTC (14 hours ago)
        
 (HTM) web link (clojure.land)
 (TXT) w3m dump (clojure.land)
        
       | germandiago wrote:
       | 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.
        
         | jwr wrote:
         | 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 wrote:
           | Yes, my gut feeling tells me that sticking to functional +
           | modern platform is safer. Having structure can also be seen
           | as an advantage IMHO.
        
           | germandiago wrote:
           | 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.
        
             | stepbeek wrote:
             | 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/
        
               | germandiago wrote:
               | 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?
        
               | erichocean wrote:
               | 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.
        
             | didibus wrote:
             | 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.
        
         | Kototama wrote:
         | 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 wrote:
           | 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 wrote:
         | 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 wrote:
           | 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 wrote:
             | 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 wrote:
               | 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)
        
               | pjmlp wrote:
               | 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.
        
         | vindarel wrote:
         | 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...
        
           | CaptainOfCoit wrote:
           | > 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.
        
         | didibus wrote:
         | 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.
        
         | jakebasile wrote:
         | 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.
        
       | frou_dh wrote:
       | There's an existing site for this: https://www.clojure-
       | toolbox.com/
        
         | brettatoms wrote:
         | 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.
        
           | brettatoms wrote:
           | Also, here's the project repo:
           | https://github.com/brettatoms/clojure.land
        
       | wlkr wrote:
       | 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.
        
         | brettatoms wrote:
         | I added an issue for this comment:
         | https://github.com/brettatoms/clojure.land/issues/5
        
         | pgt wrote:
         | 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?).
        
         | weavejester wrote:
         | > 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?
        
           | johnfn wrote:
           | > 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.
        
             | dragandj wrote:
             | 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)...
        
       | matesz wrote:
       | 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.
        
         | Qerub wrote:
         | > 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...
         | .
        
           | lgrapenthin wrote:
           | Maybe not "elegant", but quite readable compiler impl.
           | compared to what I have seen. And which (real world) compiler
           | has an "elegant" implementation anyways.
        
       | gengstrand wrote:
       | 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?
        
         | lgrapenthin wrote:
         | 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.
        
         | tincholio wrote:
         | 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.
        
         | brettatoms wrote:
         | 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
        
       | moi2388 wrote:
       | 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 :)
        
         | rhubarbtree wrote:
         | How so?
        
       ___________________________________________________________________
       (page generated 2025-10-26 23:00 UTC)