3 ms·

Author here, glad to answer any questions about Jolt.

by yogthos 2mo ago

micro2588 2mo ago
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.
- yogthos 2mo 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. I wrote up a post on how this works here https://yogthos.net/posts/2026-08-07-portable-jolt.html https://yogthos.net/posts/2026-08-07-portable-jolt.html
  - micro2588 2mo ago
    Really cool, I see now that most all the the Racket extensions to Chez have been up-streamed which is positive for the health of both projects.
    - yogthos 2mo ago
      Indeed, it's a nice ecosystem to be part of. :)
iainctduncan 2mo ago
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.
- yogthos 2mo ago
  Hi, thanks, glad to hear you enjoy my other work! :) 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/host-interop.html https://jolt-lang.github.io/docs/native-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 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 https://github.com/jolt-lang/glimmer It ended up working pretty well for a project here https://github.com/yogthos/splat-painter 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.
saityi 2mo ago
It's neat! 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?
- saityi 2mo ago
  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.
  - yogthos 2mo ago
    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.

Author here, glad to answer any questions about Jolt.

by yogthos 2mo ago

Author here, glad to answer any questions about Jolt.

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.

yogthos 2mo 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. I wrote up a post on how this works here https://yogthos.net/posts/2026-08-07-portable-jolt.html https://yogthos.net/posts/2026-08-07-portable-jolt.html
- micro2588 2mo ago
  Really cool, I see now that most all the the Racket extensions to Chez have been up-streamed which is positive for the health of both projects.
  - yogthos 2mo ago
    Indeed, it's a nice ecosystem to be part of. :)

iainctduncan 2mo ago

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.

yogthos 2mo ago
Hi, thanks, glad to hear you enjoy my other work! :) 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/host-interop.html https://jolt-lang.github.io/docs/native-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 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 https://github.com/jolt-lang/glimmer It ended up working pretty well for a project here https://github.com/yogthos/splat-painter 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.

saityi 2mo ago

It's neat! 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?

saityi 2mo ago
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.
- yogthos 2mo ago
  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.