HN Debrief

Jolt: Clojure compiler implemented with Chez Scheme

  • Programming
  • Open Source
  • Developer Tools
  • AI

Jolt is an attempt to rehost Clojure on Chez Scheme, with the goal of running existing Clojure code as native binaries while keeping enough of the familiar ecosystem to feel like a practical JVM substitute. The author says the project is not trying to redesign the language. It is porting an already well-specified one, then using existing library test suites, a conformance corpus, and JVM comparisons to drive compatibility and performance. That framing landed with people. The speed looks less magical when the job is "make this known thing behave the same on a new runtime" rather than invent a new language from scratch.

If you care about shipping Clojure outside the JVM, Jolt is worth watching now for internal tools and small native apps, especially where C library access matters. Treat it as promising but early, and validate library compatibility and performance on your own code before betting production systems on it.

Discussion mood

Mostly excited and curious. People like the idea of a slimmer native Clojure runtime and several were impressed that simple programs already build and run, but there was a sharp vein of skepticism about the project's age, the pace of development, and undisclosed LLM-heavy coding.

Key insights

  1. 01

    Compiler ports fit LLM workflows well

    Porting a mature language to a new runtime is unusually friendly to LLM-assisted coding because the desired behavior is already pinned down. The language semantics exist, the tests exist, and the developer can judge each translation step against known outputs. That makes the model less a designer and more a fast syntax-aware typist, which is very different from asking it to invent architecture in a vague greenfield project.

    If you are evaluating AI-written systems code, separate "port with oracle tests" from "novel design." LLM speed is more believable in the first case, so your diligence should focus on conformance suites, benchmark harnesses, and compatibility claims.

      Attribution:
    • yogthos #1
    • iainctduncan #1
  2. 02

    Jolt is chasing JVM compatibility first

    The distinguishing bet is not just native binaries. It is shim layers that mimic enough of the Java standard library for existing Clojure libraries to run with minimal changes. That turns Jolt from a fresh dialect into a compatibility project, and it explains why the author highlights supported libraries, user-space shim APIs, and running upstream library test suites instead of language novelty.

    Read Jolt as an ecosystem bridge, not a blank-slate Lisp. The right evaluation question is whether your dependency stack lands inside its shimmed surface area, not whether the core language looks elegant.

      Attribution:
    • yogthos #1
  3. 03

    Jank and Jolt are solving different problems

    jank is going after seamless C++ interop, native dependency builds, and a more novel runtime story. Jolt is trying to be a drop-in host for existing Clojure code. That split matters because these projects can look similar from the outside, yet one is optimizing for calling arbitrary C++ libraries and the other for getting today's Clojure libraries to pass unchanged through shims and conformance tests.

    Do not compare native Clojure runtimes by headline alone. Choose based on your boundary conditions: existing library compatibility points toward Jolt, while deep C++ integration and native build tooling point toward jank.

      Attribution:
    • Jeaye #1 #2
    • yogthos #1
  4. 04

    Browser support is a portability demo

    The Gambit backend is not being positioned as a serious replacement for ClojureScript in the browser. The author treats JavaScript output as proof that Jolt now has a portable Scheme layer that can ride multiple backends. That is a technical milestone for the runtime architecture, not a product claim about frontend development.

    Do not infer a frontend roadmap from the JavaScript angle. The strategic signal is backend portability across Scheme implementations, which could widen platform reach without making web development the primary target.

      Attribution:
    • yogthos #1
  5. 05

    Native FFI is how missing runtime features get filled

    The project is not pretending Chez Scheme already has every service the JVM provides. The author describes using Scheme interop and native FFI to build replacement layers such as time handling, crypto, JDBC-adjacent pieces, and even GTK-based UI libraries. That shows how Jolt plans to close ecosystem gaps in practice: thin host integrations wrapped in Clojure-friendly APIs.

    Expect the long tail of compatibility to be solved library by library through FFI-backed shims. If you adopt Jolt, budget for some host-specific glue around time, databases, crypto, and system libraries rather than assuming JVM parity out of the box.

      Attribution:
    • yogthos #1

Against the grain

  1. 01

    Velocity and polish can hide fragility

    The skeptical read is that two thousand commits in two months, a polished site, and a burst of adjacent repos are exactly the pattern people now associate with LLM-generated overproduction. From that angle, compatibility claims and demos are not enough. A young runtime can still be brittle in the corners that matter once you move beyond toy apps and benchmark harnesses.

    Keep your standards high for new language infrastructure even when the demos are smooth. Run your own dependency graph, error cases, and operational tooling before treating fast progress as proof of robustness.

      Attribution:
    • davexunit #1 #2 #3
    • YorickPeterse #1

In plain english

Chez Scheme ↩
A high-performance implementation of the Scheme programming language that can be used as a runtime and compiler target.
Clojure ↩
A modern Lisp dialect that runs mainly on the Java Virtual Machine and emphasizes immutable data and concurrency.
ClojureScript ↩
A version of Clojure that compiles to JavaScript for running in web browsers or other JavaScript environments.
FFI ↩
Foreign Function Interface, a way for code in one language to call functions and use data types from another language, often C.
Gambit ↩
A Scheme implementation and compiler that can target multiple backends, including JavaScript.
GTK ↩
GIMP Toolkit, a widely used library for building graphical desktop applications.
JVM ↩
Java Virtual Machine, the runtime that executes Java bytecode and also hosts languages like Clojure.
LLM ↩
Large language model, a machine learning model trained to predict the next token in text.
shim ↩
A compatibility layer that imitates one API or runtime behavior on top of another system.
Squint ↩
A lightweight Clojure-like language tool aimed at producing JavaScript with low overhead.

Reference links

Project and documentation links

Author posts and implementation details

Related language projects

  • jank
    Closest comparison point raised repeatedly, another native Clojure implementation with different goals
  • jank object model post
    Explains why jank's protocol and record support has taken time and how its runtime model differs
  • Janet
    Mentioned as another Lisp focused on standalone binaries
  • let-go
    Another Clojure implementation, this one in Go

Interop examples and libraries

  • Coffi
    Recommended as a nicer way to use Java Panama FFI from Clojure on the JVM
  • sqlite4clj Coffi example
    Concrete example showing what JVM-side FFI bindings can look like with Coffi
  • Jolt time library
    Example of using FFI-backed shims to replace Java time features for existing libraries
  • Glimmer
    Example Jolt library using FFI to build a GTK reactive UI layer