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.
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!
Thank you! How about performance? Do you see Jolt evolving into something more useable for real work, or is it too niche and not capable enough? I always loved Racket. How does Jolt compare? I'll give it a try this weekend.
I think the name being the same is worth bringing up. Ideally you would avoid name collisions with big projects but admittedly it does happen all the time.
Yes, and people seem to leave context out of it nowadays, which usually makes it a moot point. When searching I would put "Jolt Chez" or "Jolt Clojure" to get relevant hits. There is a Jolt energy drink too, popular among techies, or it was...
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.
Congrats, this is awesome! I have followed your writing and have your book, so was excited to see this was you.
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.
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
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?
I was able to fix the System/in issue (I didn't actually need that, just *in*) and load it with jolt. This is quite neat! I see now it just follows all of the `:clj` conditionals and covers everything you'd need.
Glad you got it working, and yeah it is just standard reader conditionals. I've also look for .jolt files which get preference over .clj, so it's possible to add Jolt specific behavior which overrides existing behavior in a library.
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.
Oh I would definitely recommend ClojureScript or Squint for running in the browser. Using Gambit to compile to Js was really just an illustration of how Jolt has a portable layer that can be compiled to a completely different Scheme backend. I don't really intend to compete with the existing frontend solutions because you really want to keep your dialect as light as possible to minimize the size and friction with the existing Js ecosystem.
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.
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):
62 comments
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.
However to be fair, none of it came to mind when I saw the title.
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.
(not just JVM and JavaScript runtimes)
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).
Have to give it a try.
https://www.piumarta.com/software/cola/