Clojurians Log v2
announcements 2026-08-28
Just posted https://www.clojuriststogether.org/news/august-2026-short-term-project-updates/ (Clojure LLM: Dragan Djuric, Gloat and Glojure: Ingy dot Net, and PluMCP: Shantanu Kumar). Thanks for the great work!
Hello! I updated the https://github.com/damesek/hnsw-clj "clojure native" implementation of hnsw algorithm. What is new: The latest version introduces reference-aligned HNSW construction, true shared-graph parallel indexing, and an optimized float32 SIMD search path. Compared with the previous version, the 10k × 768 index build dropped from 69 seconds to 4.49 seconds, while 10-thread full-Bible (my test db) search throughput increased from roughly 10.6k to 20k QPS. These improvements preserve essentially the same recall, halve search-vector memory usage, and keep the complete search engine inside the JVM without external C++ or JNI dependencies. In short: indexing now working, but still slower vs python native solution (bigger db - more visible difference), hnsw query faster than python - that is quite stable. Lot of to do left, what is practical. It could be a good base approach.
Nice work! Maybe you will find my work on https://github.com/replikativ/proximum/ interesting. It implements a competitive HNSW version in Java.
I check it! Sounds interesting! :)
https://raygui-jnk.b12n.app -- raygui's control suite in jank, with raygui built as an ordinary jank package First release. raygui is raylib's immediate-mode GUI library and ships as a single header with no package anywhere, so there was no way to reach it from jank until now. • 24 examples across 7 groups, one screenshot each • 53 of raygui's 61 functions bound in one namespace • no FFI and no hand-written signatures -- jank compiles through C++, so the header is the binding • one dependency line for any jank project, no vendored copy needed • six vendored themes, palette and embedded font both loaded from the .rgs https://raygui-jnk.b12n.app https://github.com/burinc/raygui-jnk
I’ve open sourced a Clojure-adjacent project I’ve been working on: Kvist, a Lisp for systems programming that compiles to Odin.
Kvist has essentially the syntax of Clojure that I love to read and work with, as well as macros, interactive development with a REPL, data-oriented DSLs, and composable collection transforms. But the execution model underneath is Odin and very different from Clojure. It’s not immutable by default, ordinary values are statically typed and native, memory management is explicit, there’s no VM or GC.
Kvist has an explicit immutable Data type that’s essentially EDN in memory. That means Hiccup-style HTML, Datomic-style transactions, Datalog queries, pull patterns etc. can be written naturally as Lisp data. Transforms such as map, filter and keep can be fused into direct loops without lazy sequences or intermediate collections.
Attached is a short demo of the native REPL.
https://github.com/kvist-lang/kvist
Yes, direct interop with Odin. You can even mix Kvist and Odin source code in the same package.
My mind is officially blown!
What’s your use case for this, @andreas891? And what do you see as good fits generally? Game dev? Embedded? Desktop apps?
😄 @pez My personal use cases are mainly CLI’s and desktop applications – the places where Clojure struggles with startup time and/or binary size and/or memory usage. Odin and Kvist are perfectly good choices for web servers as well, and there are some good arguments with regards to resource usage running on small VPS’s etc, but I really love Clojure for web – I’m still keeping my services in Clojure for now. Odin is very well known for game dev and simulations, but truly is general and positions itself as a modern, better C replacement. It’s not the best for embedded though, as it expects to run on a modern operating system. I’m currently building a quite large and ambitious native macOS app with Kvist/Odin. And I have another big open source project written in Kvist which I’ll announce soon, sneak preview: https://github.com/vevdb/vev – An embedded Datalog database for immutable database values (Native, embedded Datomic)
I will start with checking how Calva works with the Kvist REPL. Then I think I will try to use it for a desktop app I have been wanting to create a while and where Electron feels way too heavy.
Amazing. The REPL is quite fresh out of the oven. It’s quite featureful, but further performance work is needed for a truly smooth experience.
And repl evaluation works by doing full completion of every form?
So there's no interpreter here, only compilation?
Yes. Each complete submissionn goes through the full compiler pipeline and runs as native code, there’s no interpreter. State persists in a resident native worker, so earlier forms aren’t replayed, and later submissions are compiled incrementally. That does make evaluation naturally a bit slower than in a Clojure REPL because each submission still requires native compilation and loading.
That's cool. I wanted to do something similar for rust but compilation time is no-go there
Very cool! Just out of curiosity, what was the main reason you didn’t want to use Jank?
jank is a great effort and I have played with it. Last I tried it produced big binaries, similar in size to what graalvm native-image does, which was one of the things I wanted to avoid for the projects I had in mind. jank is also a true Clojure with pervasive persistent data structures and great dynamism, which does come at a cost in speed (smaller) and memory usage (larger) -> tradeoffs. Kvist is not a Clojure dialect. It’s better thought of as Odin in Clojure-ish syntax and with some of Clojure’s affordances.
Wow, so how big are Jank binaries?
#C0AQSC6C3L0 is a Copilot and Cursor extension and MCP server that provides AI agents with #CBE668G4R tools. New version just released: https://github.com/BetterThanTomorrow/calva-backseat-driver/releases/tag/v0.0.40 • https://github.com/BetterThanTomorrow/calva-backseat-driver/issues/63. The registry has an AI agent interface, mainly through: ◦ bb list: Discover and find connect information. Ask your AI agent to connect you, and it will do it. ◦ bb mcp: A one-request-at-the-time command that speaks MCP-ish. For bots and agents that can’t run an MCP connector on the VS Code machine (e.g. Grok Bots, at the time of this writing) Now it is much, much easier to connect VS Code-external AI harnesses to your project’s Calva REPL sessions. Even Grok Bots, which can’t connect an MCP server running on the local machine, can use the Calva tools, with bb mcp.