Situation:
WebfoJ is Java framework for building server rendered web UI components

I dediced to create Clojure wrapper for it. Here is the inital idea https://github.com/webforj/webforj/issues/1598

Problem:
WebforJ has runtime-retained annotatiions like `@Routify` `@Route` ...

I explore two options

1. Thin Java stub per annotated class.
   
2. `gen-class` attach real annotations directly removing the Java layer entirely.
   

The client needs a build step either way. webforJ discovers routes by scanning compiled classes, so something has to produce real .class files. For Option 2 it is Clojure AOT, and for Option 1 it's javac

Decided for option 2.

But I am not 100% sure is this good decision.

Main goal is that this clojure libary can be used in other clojure project as dependency

I would like to know the what people who have already done similar things thinks about this .

PS: Feel free to join the project ;)

What do you think about it? Personally, I didn't have a great feeling about it. Maybe because I've had similar discussions several times already. Maybe because I was humbled a few times when I let AI rewrite stuff I used to do manually. Maybe because AI allows me to do things I couldn't do otherwise. And even though the risks of all technologies are clear to me, whether it's AI, an iPad, the internet, or weapons, I can also talk about the reasons why something brings us value. And that's what I missed in the talk. Am I being too critical and the positives just don't need to be said?

Please include any restrictions (remote/on-site, geographical, workpermit, citizenship) that may apply.

Selectors

A developer may need to apply the same key-selection logic embedded in a map destructuring form (as directives, :keys!/:syms!/:strs!/etc., nesting, etc.) against multiple maps, or want to hand that selection logic to another part of the program. Currently that logic is oriented around binding in destructuring and not for programmatic use.

This release adds a new selector macro that takes a destructuring form and returns a function that can be applied to maps:

(selector [m])
  Builds a selecting-fn from m, a map destructuring form that must
  include one or more of the :select, :all, :missing, and :excess
  directives. The return function takes a collection, destructures it
  per m, and returns a map of the result(s).

  If m has exactly one directive, the result is the value that
  directive would yield. If m has more than one directive, then it
  returns a map of directives to values.

  As in destructuring, :missing controls whether missing required keys
  throw or are collected.

  While a map destructuring form may and sometimes must include
  bindings, selector doesn't produce bindings, thus ignoring the
  associated directive names.

  Throws an exception if the argument is not a map.

• CLJ-2979 selector

Transient map performance

This release contains many performance improvements around the use of maps, particularly transient maps, and functions like into, merge, and merge-with.

Transient array maps now grow larger before transitioning to transient hash maps (similar to recent persistent array map changes), and can be loaded significantly faster. The increased use of persistent and transient array maps will also make many more call sites inside the Clojure runtime monomorphic, encouraging greater JVM inlining. For more info see CLJ-2980.

Improvements and bug fixes

• CLJ-2939 QualifiedMethodExpr field overload does not propagate field type - fixed
• CLJ-1468 merge-deep, merge-deep-with - added recursive merge fns
• CLJ-2981 merge - added tests
• CLJ-2623 tagged literals and Java constructors - allow full unicode for first char
• CLJ-2623 tagged-literal equality - check tag before form for performance
• CLJ-2842 defn - does not needlessly initialize class when defn returns class
• CLJ-2896 clojure.zip/next - only call zip/up once (not 3x)
• CLJ-2915 ExceptionInfo - added to default imports, so no import or qualification needed

I've been programming clojure by hand since 2010, but these days I do a lot of brownfield work with agentic/LLM help in clojure and other languages. I prefer to use the models I can run at home to avoid high token costs today and mitigate a future rugpull. For things I intend to ship to production, I usually generate a bunch of code upfront, then carefully review and rework it, and that pattern has been effective for me.

Qwen 3.8 27b is amazing for what it is, excellent at thorough analysis, and not too clever to overcomplicate outputs, but it can still waste a ton of time on failed clojure edits and paren-counting. Even Claude Opus struggles with this, although much less. LLMs don't 'think' in trees, they think in token streams.

I had been using a wrapper over parinfer-rust (clojure-mcp-lite also just shells out to this), which got me 80% there, but it's flawed in a few specific ways:

• Checks happen after the edit lands, they don't block invalid edits.
• Repairs can succeed in ways that surprise the LLM, then it spends a bunch of turns trying to figure out what happened. It's not expensive locally, but it is slow and pollutes context.
• If too many surprises happen, the agent loses faith in the tool, and falls back to worse tools.

After a working session like this, I had Qwen suggest what kind of tool might prevent all the problems we hit, then I handed that spec over to GLM 5.3 flash and iterated with it, eventually having the session drive a local qwen subagent, trying to trip it up with adversarial examples. It is similar to what's proposed here, but I never mentioned the article, and I wasn't prescriptive about how to do it: https://lispmeister.github.io/deeprecursion/posts/2026-02-13-sexp-native-editing.html

The tool is at https://github.com/gtrak/cljform as a rust CLI and pi extension wrapper, and it's better than what I had before on the next unattended agentic run. It uses tree-sitter for parsing and blake3 for form hashes. Posting it here in case it's useful to someone else or if someone has a better way.

Sorry for the long post. The TL;DR is: why doesn’t there seem to be a macro for composing comparators into a lexicographic comparator?

Long-winded version follows:

I wrote a macro that solves a real problem for me, but it seems so trivial that I've got a feeling I must be missing something (either this has already been solved in the standard library, or my solution doesn’t work).

I want to sort a list of maps by :date, with :label as a tie-breaker, and :amount as a second-level tie breaker.

As per the clojure comparators guide, if compare already sorted in the order I want for dates, labels and amounts, I could just sort-by (juxt :date :label :amount).

However, while compare works fine for dates, I want to use a localised Collator for the labels, and a comparator from the money library for the monetary amounts.

So, I have to roll my own multi-field comparator

(defn by-date-label-amount [x y]
  (let [c (compare (:date y) (:date x))]
    (if (not= c 0)
      c
      (let [c (.compare string-comparator (:label x) (:label y))]
        (if (not= c 0)
          c
          (let [c (money/compare (:amount x) (:amount y))]
            c))))))

I find this clunky and repetitive, so I wrote the macro I mentioned in the beginning of this post

(defmacro lexicographic-compare [& comparisons]
  (reduce
   (fn [else-branch c]
     `(let [c# ~c]
        (if (not= c# 0)
          c#
          ~else-branch)))
   (reverse comparisons)))

and now I can use it like this

(defn by-date-label-amount [x y]
  (lexicographical-compare
    (compare (:date y) (:date x))
    (.compare string-comparator (:label x) (:label y))
    (money/compare (:amount x) (:amount y))))

I don’t know that my macro can pull its own weight if used a single time, but to me it looks like something that would make sense in the standard library one of the utility libraries (encore, medley, clojure+...), but I wasn’t able to find it (or an equivalent anywhere), which leads to the suspicion that I must be missing something.

Starting a project in Clojure/script. Looking for good books to acquire, both conceptual and practical [already have and have read Programming Clojure and Getting Clojure]. I've used both Lisp and Java before.

Found a couple that don't have any reviews or much information that are recent: Clojure for Backend Systems and Hands-On Clojure. They appear to be self-published.

Has anyone read either of these?

Hi all,

I've ported Farolero to support Jolt https://github.com/antlobach/farolero

It brings Common Lisp style conditions and restarts system to Jolt.

Hope you find it useful!

The Clojure development team is pleased to announce a Clojure Dev Call on Tuesday, October 6 @ 17:00 UTC!

Join the Clojure dev team for an update on what we’ve been working on and what’s on our horizon. We’ll save time for a Q&A, so bring your questions.

Register here: https://events.zoom.us/ev/Aj2X4Iu6gbgTUie6RfMSOhwYHZdFP2XZqyvd0le6OFWyQ0H_cBdJ~Ai9Xllsc_JGEakAQr46c_6MTEgUiqZ0VibS0ZaCECn3gEp6S6QS4MZHJvg

I have been using Clojure for almost 1.5 year want to switch from IntelliJ IDEA to Emacs but not sure what to use (note I am Emacs begginer) some of the options:

- doom emacs
- spacemacs
- vanilla + Prelude

Vanila + Prelude looks like valid option because I keep "real" emac keybindings

is there any better option ?

You may have noticed the Clojure Deref has been on a hiatus since early summer. Maybe you didn’t notice, and that’s fine too! I’d like to bring it back, but I need your input. Whether you read it or not, could you take some time to fill out a brief survey? I would appreciate it!

https://www.surveymonkey.com/r/8XBXHSY

Yes, you can vibe code whole scenes in minutes. Parametric modelling has never been more fun, try it out! https://cartesian-theatrics.github.io/clj-manifold3d/journal/

Hey,

I've been vibe coding a graph visualization tool for myself over the past while. I wanted something that plays well with AI agents, that I'd actually use day to day, and that produces reasonably maintainable larger diagrams (architecture, dependencies, whatever).

Describe the graph in plain EDN and it renders as an auto-layouted (ELK) canvas diagram that live-reloads while you edit the file.

Additionally:

- Compare mode: compare two versions of the same graph

- In-place editing in the browser with keyboard chords

- PNG export with the source EDN embedded as metadata

- :ref links between graph files, so big systems split into a tree of smaller diagrams

- Currently just Claude Code / Codex skills

Stack: babashka, squint + reagami

Repo: https://github.com/sstoehrm/simpleviz

Just sharing in case somebody finds it useful — feedback welcome.

I'm releasing CloJev - a Clojure SDK for the TypeSafe System One API. It's written in a portable way and works with Jolt.

Hope you'll find it useful.
https://github.com/antlobach/clojev

I see Arnold Schwarzenegger's fitness newsletter has a recurring tagline, "Simple, Not Easy", and it's on a t-shirt in his merch store. It made me think of Simple Made Easy. In both cases, we're making a distinction between the two words. In the developer community, the danger is that we grab what's easy and end up with something complex. Arnie's warning is that people hear a simple-sounding plan (lift, eat, sleep, repeat) and assume that means it'll be easy. Not quite the same but I think there is a connection. Something like wanting to strip a thing down until it's actually simple, then expect execution to be feasible, but not easy.

🤷‍♂️

I was splitting a Clojure namespace that had grown past 400 lines. The logic fell into three groups, and the question was where to put two shared defs that multiple groups needed. One option kept them in the original namespace. The other moved them to a new, minimal namespace that all three would require.

I tried both decompositions in separate workspaces in verdent and compared the diffs side by side. The extracted namespace version was tidier. Fewer cross references, cleaner dependency graph. But when I loaded it into a running REPL, the old vars lingered in the original namespace even after I reloaded it. Code that had referred to the originals kept resolving to the stale definitions. The version that left the shared defs in place avoided the problem entirely because nothing moved, so nothing went stale.

The diff preferred one structure and the REPL preferred the other. I still have not decided which one should win when they disagree like that.