undefined

points

[-]

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.

by yogthos18 hours ago|

parent|

[-]

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

by micro258818 hours ago|

parent|

[-]

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.

by yogthos18 hours ago|

parent|

[-]

Indeed, it's a nice ecosystem to be part of. :)

by iainctduncan16 hours ago|

prev|

[-]

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.

by yogthos15 hours ago|

parent|

[-]

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/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.

by saityi14 hours ago|

prev|

[-]

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?

by saityi11 hours ago|

parent|

[-]

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.

by yogthos10 hours ago|

parent|

[-]

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.