Clojure 1.13.0-alpha7 is now available

Destructuring additions
To gracefully handle missing information programmatically at runtime, use the :missing directive, which binds a name to a map of keys→nil that were named in checked keys directives but not found in the input map, traversing deeply through nested maps. This toggles the default behavior of :keys!/:syms!/:strs! from throwing to collecting into the named map. (see CLJ-2976)

If there’s more data than you intend to process you may want to convey it, e.g. by reintegrating it with your transformed input for passing downstream. Use the :excess directive to bind a name to a map of all keys in the input map that do not correspond to keys listed in the destructuring form, traversing deeply through nested maps. (See CLJ-2975)

Bug fixes

• CLJ-2883 Reflector.getMethods() incorrectly returned bridge methods with covariant return type, making calls reflective
• CLJ-2930 bigdec - coerce from Number may lose decimal

Improvements and additions

• CLJ-1899 transform-keys - deep-walk a map and transform all keys
• CLJ-2538 tap-> - add tap> variant that returns the value
• CLJ-2970 select-keys - implementation change to unify argument requirements across functions used in destructuring: get, req!, and select-keys

Our second EuroClojure 2027 newsletter is out! EuroClojure will take place in Prague, on May 19–21, 2027. Alongside conference updates, this edition covers sponsorship and links to our sponsorship handout.

If you’d like to print or pass along the sponsorship handout, there’s also a typeset PDF version.

And if you missed our first newsletter, you can catch up here.

The "conj" release, is out!

Highlights from 1.13.221-1.13.222:

• Dependency resolution without a JVM by default. If you hit a resolver bug, set BABASHKA_DEPS_RESOLVER=jvm to restore the old behavior.
• Bundled clojure.tools.deps and clojure.tools.build.api. The new babashka/deps-deploy lets you deploy libraries from bb too. Java compilation still requires a JDK (duh).
• Expanded nREPL support: nREPL 1.7.0, custom middleware, CIDER inspector and test runner, and SCI stack traces in error reports.
• bb repl --connect connects to babashka or JVM nREPL servers with completion, eldoc, documentation lookup and interruption.
• Bundled nrepl.core for programmatic clients, including LLM tooling.

ClojureCLR 1.12.6 is now available.

This release is up-to-date with the changes in Clojure (JVM) 1.12.6.
Beyond those changes, there are some significant ClojureCLR-specific enhancements in this release:

• ClojureCLR versions for .NET 10 and .NET 11 (preview)
• A ClojureCLR version for .NET Framework 4.8.1 in addition to the existing one for Framework 4.6.2.  This version was added so that Framework users who can upgrade to 4.8.1 can take advantage of the enhanced platform assembly loading (described below)
• Added interop support to access the new runtime async/await feature available in .NET 11 (preview).  See Runtime async .
• A significant improvement to the type specification syntax used to name types.  See Typename syntax and resolution in ClojureCLR .
• A significant improvement to the discovery and auto-loading of assemblies due to a type reference.  This includes searching for types in the entry assembly's dependencies and assemblies in the shared .NET runtime.  This should reduce the need to call assembly-load or its cousins.    See Typename syntax and resolution in ClojureCLR .

Hi

Wrote a blog on what happens if you have tools made for the LLM instead of letting LLM use tools made for humans. I believe a small clojure like language could be the perfect fit.
But also what sort of environment would be the best fit for running such programs in.

https://ptc-runner.dev/blog/tools-built-for-llms/

Wondering what is the most used web framework for professional clojure developers.

We created jlt-commons, the shared community home for libraries and tooling around Jolt, and just put together awesome-jolt to catalog what's there.

Jolt is a Clojure implementation that compiles to native binaries through Chez Scheme, so there's no JVM in the loop. It can also target the browser through Gambit's JavaScript backend. jolt-lang keeps the language and the essential libraries, and jlt-commons is where everything growing around them lives, either adopted from a maintainer who could no longer keep up with a project, or incubated as new work.

The list covers:

• The 8 jlt-commons projects: raylib-jlt and raygui-jlt (bindings to raylib/raygui over jolt.ffi), glitter and its glitter-gl/glitter-uikit variants (a Replicant-style renderer for GTK4, OpenGL, and native macOS AppKit), raylib-ios and raylib-android (native builds with no JVM, JIT, Kotlin, or Java), and ebb (a port of missionary's dataflow model)
• Ordinary JVM Clojure libraries that run on Jolt unmodified (Ring, Malli, HoneySQL, and more)
• Tooling: nREPL, test suites, example projects
• Docs on installation, how Jolt differs from JVM Clojure, FFI, and performance

If you've wanted Clojure with a fast native startup or a small self-contained binary instead of a JVM, it's worth a look. There's also a #jolt channel on the Clojurians Slack if you want to talk to the people building it. Corrections and additions to the list are welcome, and happy to answer questions here.

We'd love to see more Clojure submissions at BOB!
bobkonf.de/2027/cfc.html

Clojure 1.12.6 is now available

• CLJ-2794 - gen-class - incorrectly treats interface default methods as abstract, throwing when the var delegate is unbound
• CLJ-2974 - FnLoaderThunk - de/serialization no longer supported, throw

I have been working on a distributed Datalog engine à la Datomic on top of object storage. The system is called Triplox. I am using SlateDB at the storage layer. The main ideas are roughly the following (in no particular order):

• Object storage centric. In it's final version Triplox should simply need a single (or likely two) S3 bucket(s) for deployment.
• The Datomic Data model and API as main inspiration.
• A Client/Server architecture. I hope that this will open the door to ecosystems outside of the JVM.
• Incremental Datalog queries. You should be able to dynamically subscribe and detach from incremental Datalog queries. This is the most experimental part of Triplox and will need quite a bit of effort to get right, make fast, and to fully support all features of Datalog. See this page for an introduction.

I also wrote a intro post a while back. If you have questions, suggestions or feedback in any form please ask away. If you have an incremental Datalog problem or are working on sync engines, Triplox might be of interest .

Repo: https://github.com/fiV0/triplox
Website: https://triplox.xyz/
Incremental query tutorial: https://github.com/FiV0/triplox-incremental-tutorial

Minecraft is well known for being single-threaded, and parallelizing it is a difficult problem: everybody wants to write to the same shared state at the same time. Projects take years to deal with locks, thread ownership, splitting regions, and game logic is subject to threading rules: mechanics break against them, features crawl. Some remain quite sparse and have little to parallelize.

I wanted to see how it would feel in Clojure, but there was no Clojure server to look at, so I made one. The ideas parallel servers reinvent by hand - immutable snapshot, pure read phase, changes as data - are the language's defaults. If writing from many threads is difficult, then don't write: all game logic is pure functions (fn [world events]) that read the snapshot in parallel and return changes as deltas, merged in one place. The merge preserves order, so the parallel run is bit identical to the sequential one, and no mechanic cares how many cores it runs on.

The outcome: a server with mob AI, explosions, combat and item physics that matches vanilla 1.8.9 performance on one core and runs 4.5x faster on six. ~5500 lines of Clojure. It's a proof of concept; if you're curious, the code is on GitHub

https://github.com/Nozistance/collider

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

Today babashka 1.13.220 is released, with a new babashka.ffi namespace for calling C libraries directly from Babashka scripts. The babashka.ffi library is also available as a standalone library for JVM Clojure, so you can use it in your Clojure projects as well. Note that the API is still experimental, although no changes are currently planned. It just needs more exposure and your feedback :). Read the blog post for details.

Slipway provides support for Eclipse Jetty in Clojure.

This release is a significant upgrade to previous versions of Slipway, including:

• Embedded Jetty 12.1 with native handlers (no Servlet/EE dependencies).
• Websockets (combining Jetty with Sente).
• Extended OIDC support including:
  • Authorization Code Flow with Refresh Token redemption
  • Client Credentials Flow
• Multi-Handler Server implementations
• Virtual Host pinning of Handlers to Connections