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.

But isn't it kind of a one way street? We can extract clojure code from the JVM but then we cannot use its ecosystem anymore, which kinda feels like a los. Since we can use (n)REPL in all ecosystems (jvm, browser, node etc...), could we use it or a variation to have interop?

It's not like JVM Clojure is going away, we just have a bigger toolbox now.

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.

Thanks, and thanks for the effort on jank !

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 ?

Protocols, records, and the like will be implemented in jank. They haven't been prioritized for two reasons.

Firstly, historically, jank had a closed object model for performance, which I have blogged about here: https://jank-lang.org/blog/2023-07-08-object-model/

Over the past few years, I've been spending hammock time to find a solution to this to re-open the object model efficiently. I came up with a design this year which addresses the concerns raised in that blog post and opens up the object model, but jank today is still in a half-way state between the two systems.

Secondly, in the several years I've written Clojure professionally, I don't recall ever writing my own protocol, record, or struct. When I was first learning Clojure, I leaned on them more heavily, since I was coming from OOP land. But once I leaned into the pure Clojure data designs, the OOP side of things just stopped mattering. So, if I were to write just about anything in jank, I wouldn't intend on using these features. That alone has made them low priority for me.

But they'll be implemented. :) I'd estimate Q1 next year for me to tackle those.

Prtotocols tend to be useful for the same reason as Java interfaces. For example, Ring uses a protocol to specify the contract for the adapter. So, then you can just implement it and seamlessly drop in wrapper Jetty or Undertow or whatever. https://github.com/ring-clojure/ring/tree/master/ring-core-p...

> I don't recall ever writing my own protocol, record, or struct.

I'm honestly extremely surprised. Protocols seem sort of essential if you want two different "things" to exhibit the same behavior.

The whole set of immutable datastructures are fundamentally backed by them (well they use Java Interfaces but its fundamentally the same). Not entirely sure how youd implement them without Protocols

Theyre also sort of essential if you want plug-in backends for any part of your codebase.

Im curious what your go-to is currently? Do you just write multimethods and dispatch on the inferred input type?

I also rarely use multi-methods in Clojure. I just use maps and vectors and lists and keywords and strings and functions. Instead of multi-methods, I generally use a map of fns. When not writing open, extendable libraries, this is an even simpler choice which I find works well. Most of my Clojure work has been writing applications, so being able to extend in an open way is not a benefit. I'd prefer to keep everything centralized in one map.

Also, as I described above in the blog post, protocols/interfaces aren't needed to implement Clojure's object model either. They're just one approach. They're the nominal typing approach, in contrast with something like the structural typing approach, documented in the blog post. For that, we use C++20 concepts for structural typing predicates.

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.

Jolt actually does have both Scheme interop and FFI

https://jolt-lang.net/docs/host-interop.html

and it is possible to make .so libraries with Jolt as well right now

I didn't know about creating .so files, neat.

For scheme interop, maybe the page hasn't been updated? I only see it talking about Java shims?

Oh I was using that as just an example of how to do interop. I'll add more docs on that.