edit: Yup, found a very long blog post that says it's made with LLMs near the end https://yogthos.net/posts/2026-07-02-jolt.html
It has a lot of very interesting ideas going on, though ultimately i didnt end up using it (i need my persistent datastructures and seq col abstractions)
It feels very minimal and scheme-y and very different from anything ive used before. Definitely worth exploring
How much "production ready" / "battle tested" would this be ?
(Not to start a flame war, I'm genuinely curious about the differences.)
The key differentiator for jank is the seamless C++ interop, which is a problem not many people are willing to tackle, due to its scope and complexity. jank is a novel approach to this, providing incredible JIT and AOT support of arbitrary C++ libraries alongside your Clojure code, including a Cargo-inspired native build system for building your native deps along with your program (or finding them in the installed system).
For some people, there is another key differentiator, which is the amount of AI-generated code involved. My understanding is that Jolt and other newer dialects like Glojure have a lot of spunk and are exploring new ideas, given the velocity that AI-driven coding can provide. I don't see jank ever being categorized in that way.
Since you're here ;) : I read on the alpha doc that protocols and other part of the clojure object model are not done yet - is your goal to include them eventually, or is there a part of the lore of clojure that makes them not indispensable ?
Firstly, historically, jank had a closed object model for performance, which I have blogged about here: https://jank-lang.org/blog/2023-07-08-object-model/
Over the past few years, I've been spending hammock time to find a solution to this to re-open the object model efficiently. I came up with a design this year which addresses the concerns raised in that blog post and opens up the object model, but jank today is still in a half-way state between the two systems.
Secondly, in the several years I've written Clojure professionally, I don't recall ever writing my own protocol, record, or struct. When I was first learning Clojure, I leaned on them more heavily, since I was coming from OOP land. But once I leaned into the pure Clojure data designs, the OOP side of things just stopped mattering. So, if I were to write just about anything in jank, I wouldn't intend on using these features. That alone has made them low priority for me.
But they'll be implemented. :) I'd estimate Q1 next year for me to tackle those.
Jank compiles to C++, C/C++ interrop is direct, you just import and use any C/C++ library directly as if you were coding in C/C++. There's no FFI, it feels the same as how you use Java from ClojureJVM.
Jolt compiles to Scheme, but doesn't yet have Scheme interrop, though it is planned. Scheme doesn't have a large ecosystem of libraries. So Jolt is almost more of a "pure Clojure" runtime. It mostly relies on using other Clojure libraries, and provides a subset of Java for common I/O and threading ops that you'd use interrop for in ClojureJVM to get most commonly used Clojure libs working (ring, reitit, integrant, malli, hiccup, etc.)
Jolt has a C FFI, but it's not very convenient, you have to declare each C function yourself, manually manage type conversions, memory, etc.
They can both take your Clojure code and make a compiled native single binary out of it. Jank also plans to allow Jank programs to be compiled into static or shared libraries such as .so files, so they can be embedded in or depended on from C++ and other native applications.
On top of that, I expose the API for creating shims in user space, so people can easily add their own for the libraries they want to use that might not be covered in the core. And I leverage this functionality myself to create libraries for JDBC layer or crypto that rely on doing FFI to shared system libraries that aren't part of the core runtime.
In terms of how production ready Jolt is, it's still fairly new obviously, so there will inevitably be bugs. However, it already passes full https://github.com/jank-lang/clojure-test-suite from Jank, and has its own conformance corpus https://github.com/jolt-lang/jolt/blob/main/test/chez/corpus... which is a superset of that. On top of that, I'm now able to run original test suites for the libraries I support and compare them with JVM outputs to ensure there aren't unintended divergences.
The other side of it is the benchmark harness which I use to ensure performance stays reasonably close to the JVM, in most cases it's within 1.x, and the worst case is around 6x right now. https://github.com/jolt-lang/jolt/tree/main/bench
So, Jolt basically aims to be a drop in JVM replacement for running existing Clojure code.
Although it is rather verbose, and it is easier to have a C header and run jextract on it, instead of the manual boilerplate.
No idea how well AI tooling would manage.
For example look at this arc from sqlite4clj https://github.com/andersmurphy/sqlite4clj/blob/master/src/s... it's very elegant.
(Also can plug my own libvips wrapper using coffi https://github.com/outskirtslabs/vips)
Using FFI/FFM "vanilla" with java interop is also viable, and in my experience the SOTA models do just fine with it (with or without jextract).
I wrote up a post on how this works here https://yogthos.net/posts/2026-08-07-portable-jolt.html
I have one question, can one drop into Scheme the way one can call Java in clojure, or is one totally firewalled from the underlying Scheme implementation?
Great to see Gambit getting love too. Gambit and Chez are amazing achievements.
And yes, you absolutely can drop both down to Scheme and do FFI to drive native libs as well
https://jolt-lang.github.io/docs/host-interop.html
https://jolt-lang.github.io/docs/native-interop.html
I actually leverage this myself in libraries, I ended up writing a Java time layer to support tick here, and I decided to make it a library since I wanted the core executable to stay self contained, and Chez doesn't provide timezone handling natively. So, time pulls in a shared system library and shims a Java style API over it that tick can use
https://github.com/jolt-lang/time
And I'm doing FFI in Glimmer to provide a Reagent style reactive library on top of GTK
https://github.com/jolt-lang/glimmer
It ended up working pretty well for a project here https://github.com/yogthos/splat-painter
Definitely excited with the progress so far. It's obviously still very fresh, and there are likely bugs and quirks abound, but I find it's already quite usable for my own personal projects.
How does this fit into the ecosystem compared to something like Babashka?
I tried running a cross-platform (JVM, CLR, JS) Clojure project I'm working on, but it failed trying to load the JVM's `System/in`. Does Jolt handle reader conditionals? Is the intention for it to always follow the `:clj` branch or are you planning a `:cljolt` or something?
And it's a bit different from Babashka in providing easy access to Scheme and native libraries. And the code compiles to a standalone native binary. So, you can make a native GTK app for example.
The other big difference is performance. Babashka is an interpreter, but Jolt compiles the code. So, performance is close to the JVM in most cases.
I tried again with a datomic demo and it needed the source code to the open source version of datomic, so I need to do some work on that.
I just built the Chess example in my Clojure book and the executable was a tiny 18M.
(not just JVM and JavaScript runtimes)
https://github.com/nooga/let-go
Fun fact. It also runs on plan9:
I don’t know how to get a feeling about the actual state of projects like this anymore, so I always remain a bit suspicious. In Clojure, there is the (Rich Hickey inspired) design philosophy of “hammock driven development”, where we don’t rush things, let them simmer while lying in the hammock, sleeping on them, taking a walk, etc. Makes me wonder if projects like this are too rushed these days without thinking things through, discussing design decisions and getting ideas from other people, letting them mature over time. This isn’t specifically about Jolt (I don’t know much about it or its creator), it just inspired the thought, especially when comparing it to projects like Jank which has been years in development, with lots of feedback from the community and Clojure core maintainers as input.
Once I had the basics bootstrapped, it was really a matter of getting tests passing, and then getting more and more libraries to run on it which allowed me to exercise their own tests. And that's what really made the whole thing possible. It's sort of the ideal scenario where you have very well specified inputs and outputs, and a ton of existing tests to ensure you are implementing the behaviors correctly.
The only other aspect here is performance, and that's addressed by having an extensive benchmark harness which compares with JVM timings. This allows me to see where performance gaps are, and focus on addressing them.
I would be careful in extending my experience of being able to port Clojure to Chez Scheme runtime to working with LLMs in general because in most cases you don't have such well defined parameters when you start.
I love the expression "the hammock time has already been spent": it is actually very accurate and I'm very grateful to the Clojure team and community for spending that time!
However, you're right to point out that the development is moving really fast.
I'm building a Clojure compiler for machine learning (https://github.com/sheaf-lang/sheaf), and after 9 months, it's still very far from being production-ready.
If a dev is competent and has enough experience actually writing code and making good design decisions, I see no reason to judge their work on the basis of what tools they used to get the job done. However, it may still put me off, since I find it hard to value LLM-written code the same way I value human-written code, even though it may be equally good or even better in quality.
What would you call 2k commits in 2 months by a single committer if not slop?
I don't think "2k commits in 2 months" is enough to dismiss as slop when it's being developed by a competent Clojure dev.
One very quick "slop or not?" test is to see if em dashes are used in the source code where they literally never make sense. It's not a great test, but it's one that consistently turns out to be good enough. The results should speak for themselves: https://github.com/search?q=repo%3Ajolt-lang%2Fjolt+%E2%80%9...
But in my case I think there are levels. In this case, the author has the expertise needed to properly design the work and assess the quality of the output. And it seems they intend to maintain and evolve the library actively and long term.
Would I prefer a serious Clojure on chez that's all hand-written, for sure, but beggars can't be choosers.
If you have specific comments about the quality of the code then I'd be happy to discuss that. Attacking other people's work because they used tools you don't understand is just toxic trolling. And the fact that you judge code quality by the number of em dashes in the comments really speaks volumes.
Maybe spend a bit of time figuring out how to use new tools effectively instead of harping on what other people are doing.
It's very telling that whenever somebody starts braying about slop, they never have anything of substance to say. All the noise you add to discussions people are trying to have is the real slop.
> What would you call 2k commits in 2 months by a single committer if not slop?
Productivity. Slop is when you push a huge volume of garbage or mediocre stuff, no?
The caveat is that this isn't typical AI slop. The author knows the subject deeply, designed the system themselves, has extensive Clojure test suites to validate against, and has basically been working on it 24/7.
Can you trust it like a compiler someone spent 7 years writing and knows line by line? Probably not. But it's closer to alpha software than useless slop. As more people use it, we'll find out how robust it is, and whatever issues exist can be fixed as they're found.
So ya, I agree you shouldn't be asked to review AI generated code the author didn't review themselves. I think the ask here is more to try it and see how complete and robust it actually is. And even that only makes sense because the author is a known expert who appears to be steering the model carefully.