As a more-or-less neutral observation (I still kind-of like the project): What I find curious - perhaps a sign of these times: After just 2-3 months in development (judging from the repo commits, obviously I have no insight into what came before), the developer already communicates Jolt as a feature-complete, polished (perhaps even mature) Clojure dialect with multiple Jolt-adapted libraries from JVM-Clojure, FFI, Fibers, already with a professional looking and marketing-focussed website, detailled documentation, nREPL support, etc. Things I wouldn’t expect so soon from a language developed (mostly?) by a single person in such an early release stage.<p>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.
Not slop, though. The main developer is Dmitri Sotnikov (yogthos), who's been around in the Clojure scene for a long time and knows what he's doing.<p>However, you're right to point out that the development is moving really fast. I'm building a Clojure compiler for machine learning (<a href="https://github.com/sheaf-lang/sheaf" rel="nofollow">https://github.com/sheaf-lang/sheaf</a>), and after 9 months, it's still very far from being production-ready.
You're right to be suspicious: it's slop.
This appears to be vibecoded but not disclosed as such. 2k commits from a single author starting from June 1st with really long commit messages and source code comments. The GitHub org has 19 additional projects that are all recently created.<p>edit: Yup, found a very long blog post that says it's made with LLMs near the end <a href="https://yogthos.net/posts/2026-07-02-jolt.html" rel="nofollow">https://yogthos.net/posts/2026-07-02-jolt.html</a>
How much does this overlap / complements something like jank ? [1]<p>How much "production ready" / "battle tested" would this be ?<p>(Not to start a flame war, I'm genuinely curious about the differences.)<p>[1] <a href="https://github.com/jank-lang/jank" rel="nofollow">https://github.com/jank-lang/jank</a>
I am the creator of jank. I am also not interested in a flame war.<p>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).<p>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.
Thanks, and thanks for the effort on jank !<p>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 ?
I have a slightly different goal from Jank because my goal is to provide a runtime that supports existing Clojure libraries. I've spent the time to map out Java standard library APIs that popular libraries use and to create shims on top of Chez that allows them to run seamlessly. You can see a list of libraries that are fully tested and officially supported here. <a href="https://jolt-lang.github.io/docs/libraries.html" rel="nofollow">https://jolt-lang.github.io/docs/libraries.html</a><p>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.<p>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 <a href="https://github.com/jank-lang/clojure-test-suite" rel="nofollow">https://github.com/jank-lang/clojure-test-suite</a> from Jank, and has its own conformance corpus <a href="https://github.com/jolt-lang/jolt/blob/main/test/chez/corpus.edn" rel="nofollow">https://github.com/jolt-lang/jolt/blob/main/test/chez/corpus...</a> 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.<p>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. <a href="https://github.com/jolt-lang/jolt/tree/main/bench" rel="nofollow">https://github.com/jolt-lang/jolt/tree/main/bench</a><p>So, Jolt basically aims to be a drop in JVM replacement for running existing Clojure code.
What a wonderful excuse to dive back into Clojure! This looks fantastic. I wonder what neat stuff might be made in Clojure thanks to a C FFI that wasn’t doable on top of the JVM.
Note that nowadays with Panama, there are more FFI opportunities in JVM implementations as well.<p>Although it is rather verbose, and it is easier to have a C header and run jextract on it, instead of the manual boilerplate.<p>No idea how well AI tooling would manage.
Coffi is a great library that makes Panama FFI/FFM painless without interop. <a href="https://github.com/IGJoshua/coffi" rel="nofollow">https://github.com/IGJoshua/coffi</a><p>For example look at this arc from sqlite4clj <a href="https://github.com/andersmurphy/sqlite4clj/blob/master/src/sqlite4clj/impl/api.clj" rel="nofollow">https://github.com/andersmurphy/sqlite4clj/blob/master/src/s...</a>
it's very elegant.<p>(Also can plug my own libvips wrapper using coffi <a href="https://github.com/outskirtslabs/vips" rel="nofollow">https://github.com/outskirtslabs/vips</a>)<p>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've been diving back into Clojure just recently and this will be something I'll be trying to use immediatley.
Besides this and jank, there is also Janet; playing in the league of Lisp to standalone binaries. It’s also cool!<p><a href="https://janet-lang.org/" rel="nofollow">https://janet-lang.org/</a>
I understand some don’t like having a JVM, but for running in the browser, what does Jolt on Gambit offer over plain ClojureScript?
Author here, glad to answer any questions about Jolt.
It's neat!<p>How does this fit into the ecosystem compared to something like Babashka?<p>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?
Congrats, this is awesome! I have followed your writing and have your book, so was excited to see this was you.<p>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?<p>Great to see Gambit getting love too. Gambit and Chez are amazing achievements.
Hi, thanks, glad to hear you enjoy my other work! :)<p>And yes, you absolutely can drop both down to Scheme and do FFI to drive native libs as well<p><a href="https://jolt-lang.github.io/docs/host-interop.html" rel="nofollow">https://jolt-lang.github.io/docs/host-interop.html</a><p><a href="https://jolt-lang.github.io/docs/native-interop.html" rel="nofollow">https://jolt-lang.github.io/docs/native-interop.html</a><p>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<p><a href="https://github.com/jolt-lang/time" rel="nofollow">https://github.com/jolt-lang/time</a><p>And I'm doing FFI in Glimmer to provide a Reagent style reactive library on top of GTK<p><a href="https://github.com/jolt-lang/glimmer" rel="nofollow">https://github.com/jolt-lang/glimmer</a><p>It ended up working pretty well for a project here <a href="https://github.com/yogthos/splat-painter" rel="nofollow">https://github.com/yogthos/splat-painter</a><p>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.
Awesome work, have you looked into using Racket's fork of Chez? It supports some additional extensions and architectures from base Chez that would seem to beneficial as a compiler target, at least that was the case a couple years ago.
Thanks, and I have good news on that front actually. I recently factored out a portable Scheme layer and got Jolt to compile against Gambit as a backend. And given that Racket is basically an extension of Chez, it should be trivial to build against it now.<p>I wrote up a post on how this works here <a href="https://yogthos.net/posts/2026-08-07-portable-jolt.html" rel="nofollow">https://yogthos.net/posts/2026-08-07-portable-jolt.html</a>
I just saw this - works great to build small self contained apps. (I just tested on macOS, also supports Linux).
Clojure hosted on Chez Scheme (same as Racket). So cool. I tried building a standalone executable for the Chess game in my Clojure book using "jolt build -m chess-game.cli -o chess_jolt" and it simply worked great.<p>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.
Curious about the executable size and performance. Mark, you started me on AI with your, "Common LISP Modules: Artificial Intelligence in the Era of Neural Networks and Chaos Theory". I have never been able to fully leave Lisp behind. I'll have to try this on my linux box. What's your take on using jolt practically for work vs. learning? Thanks!
How many years have it been there? My memory reminds me of Jolt but I very hardly remember what was it, all I remember is that it was a LISP.
You're probably thinking of Ian Piumarta's COLA project (Combined Object Lambda Architecture), which had parts named after cola soft-drinks (Coke was a lisp-like language, Pepsi was a Smalltalk-like language, and Jolt was an early implementation of Coke):<p><a href="https://www.piumarta.com/software/cola/" rel="nofollow">https://www.piumarta.com/software/cola/</a>
Nice to see further adoption from Chez Scheme.<p>Have to give it a try.
See also lg which is a clojure implemented in go:<p><a href="https://github.com/nooga/let-go" rel="nofollow">https://github.com/nooga/let-go</a><p>Fun fact. It also runs on plan9:<p><a href="https://github.com/nooga/legmacs/issues/1" rel="nofollow">https://github.com/nooga/legmacs/issues/1</a>
it's good to have even more (and more slim!) ways to run Clojure<p>(not just JVM and JavaScript runtimes)
Jolt Physics: <a href="https://github.com/jrouwe/JoltPhysics" rel="nofollow">https://github.com/jrouwe/JoltPhysics</a>