ProtoClojure: a Clojure REPL without JVM

Hi everyone,

I’m excited to share a project I’ve been developing: protoClojure, a new Clojure dialect built directly on top of protoCore, a C++20 object model and runtime kernel designed from the ground up for GIL-free multithreading, structural immutability, and concurrent garbage collection.

What is protoClojure?

protoClojure is an exploration into bringing the expressive power of Clojure semantics onto a high-performance, native C++20 runtime kernel. Rather than targeting the JVM, it leverages protoCore’s engine, allowing it to benefit from native concurrency, minimal GC pauses, and direct integration with low-level execution paths.

Why protoCore underneath?

protoCore provides a robust foundation featuring:

  • GIL-free threads and true parallel execution.

  • Immutable structures shared by structure, making concurrent data handling safe and efficient.

  • A modern runtime architecture shared with other dialects in the ecosystem (like protoST and protoScala).

It is currently in its early stages, but the core mechanics are up and running. I would love to hear thoughts, feedback, or ideas from the community regarding alternative runtime targets for Clojure semantics and native integration.

You can check out the repository and follow its progress here:

:link: protoClojure Repository

Looking forward to connecting with fellow Clojure developers!

1 Like

I’m curious how far you plan to take compatibility with Clojure’s existing semantics.

A native runtime sounds interesting, especially for concurrency, but I think the tricky part might be making sure things like equality, hashing and persistent collections behave the same way developers expect from Clojure on the JVM.

Have you considered running a shared set of behavioral tests against both runtimes? It could help catch subtle differences early, before more language features get added.

I’d be interested to see where you draw the line between staying compatible with Clojure and taking advantage of what the C++ runtime can do differently.

I am not planning to make a full implementation. It opens up space for easy deployment and experimentation of fast scripts, interworking with other languages and fast integration into the shell. It will be completely community-driven. You can read in the docs the current scope, deviations, and planned features, but that is just a best guess; it depends on feedback