I spent a couple of days digging in to Janet and what surprised me was how even though at a surface level it resembles Clojure, under the hood its actually quite radically different.

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

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.

I think the author has been very open about the use of LLMs. And while I am very wary of LLM slop, this is one use case where it makes complete sense to utilize them to the fullest. A Clojure implementation already exists for LLMs to reference, and tons of test cases to verify behavior. It doesn't get better than that for LLM usage.

Vibecoding means you don't pay much attention to the code, not the case here.

Jank is Clojure hosted on C++/LLVM, and Jolt is Clojure hosted on Chez Scheme.

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.

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. https://jolt-lang.github.io/docs/libraries.html

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.

I am the creator of jank. I am also not interested in a flame war.

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.

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):

https://www.piumarta.com/software/cola/

What does this have to do with Jolt, the Clojure compiler other than in name? Is there a port to Clojure or other connection?

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.

I've been diving back into Clojure just recently and this will be something I'll be trying to use immediatley.

Note that nowadays with Panama, there are more FFI opportunities in JVM implementations as well.

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.

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.

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?

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.

Honestly LLM’s really foster hammock driven development.

You're right to be suspicious: it's slop.

The reason it's possible to move fast here is due to the fact that I'm porting an existing language to a new runtime. All the hard work and hammock time has already been spent by the core Clojure team and the community. I'm not aiming to reinvent the wheel here. Furthermore, having worked with Clojure for nearly two decades now, I have a very good idea of what the language does, and what I need to implement on the host platform.

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.

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.

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.