Clojure + Fe · KLOH-fer · A new host for an refeshing idea

⚠️ Honest warning from the author

This might go nowhere. I’m just curious to learn about programming languages — so I’m trying to port Clojure on top of Rust. Here, I’ll share my journey and learnings about Clojure and Rust. My ignorance is immense, my laziness is legendary, and hence there is a high chance of this project failing. You have been warned.

What happens when you take one of the most elegant programming languages ever designed — one built around simplicity, immutability, and expressive power — and free it from the platform it was born on?

That’s the question behind Clofer: an experiment to port Clojure on top of Rust, giving Clojure a new home that is fast, lightweight, and owned by no corporation.

“Clojure is a beautiful language trapped in a political dependency. Clofer is Clojure finally free.”

What is Clofer?

The name says it all: Clojure + Fe — the chemical symbol for iron, which is what Rust is named after (rust = oxidised iron). Say it out loud: KLOH-fer. Sounds like Clojure’s sibling. That’s intentional.

Clofer is an attempt to implement the Clojure programming language on top of Rust, instead of on top of the Java Virtual Machine. You write Clojure. It runs natively — no JVM, no Oracle, no 2-second cold start.

JVM Clojure  →  ClojureScript  →  Clofer

Rich Hickey designed Clojure as a hosted language — one that lives inside another platform and borrows its infrastructure. JVM Clojure lives on Java. ClojureScript lives on JavaScript. Clofer would be the n^th landing: Clojure hosted on Rust, and for the first time, on a platform owned by no evil corporation and driven by no garbage collector.

; You write ordinary Clojure...
(defn greet [name]
  (str "Hello, " name "!"))

(greet "Clofer")  ; => "Hello, Clofer!"

Who is building this?

Clofer is being built by me, Karthikeyan A K, a Ruby on Rails developer and Clojure evangelist based in Chennai. You might know me from Injee—my project to automatically generate backends so developers can focus on frontend work.

The story of Clofer starts where many good side projects do: curiosity. A former employer asked me to learn ReactJS. That kicked off a journey into frontend development—and into wondering why building the backend side of things had to be so painful. That frustration became Injee, which I wrote in Clojure, the most elegant language I knew.

People in the Clojure community might know me from Clojure Diary and Clojure Book.

And somewhere along the way, the question of programming languages themselves took hold. What makes a language elegant? What makes it fast? Why is Clojure so beautiful, and why is it still chained to the JVM? What would it look like to free it?

Clofer is my attempt to find out — by building it myself.

Why does this matter?

JVM Clojure is genuinely excellent. But hosting on the JVM comes with costs that aren’t always visible until you hit them.

Cold start time. A JVM Clojure application can take 2–10 seconds to start. That kills it for CLI tools, serverless functions, and any short-lived process. Rust-based binaries start in milliseconds.

Memory footprint. A JVM app typically needs 256MB+ just to breathe. Clofer could, in principle, run in a few megabytes — making it viable for IoT devices, edge computing, and environments where compute is expensive.

True tail call optimisation. The JVM doesn’t support TCO natively, which is why Clojure requires the recur workaround. A Rust-based Clojure could have real TCO, making it a more complete and elegant Lisp.

No GC pauses. Rust’s ownership model means no stop-the-world garbage collection. For latency-sensitive systems — real-time audio, trading, game engines — this matters enormously.

Freedom from Oracle. This one doesn’t get talked about enough. Oracle’s stewardship of Java has cast a long shadow — licensing changes, the decade-long Google lawsuit, constant uncertainty. Even GraalVM (the community’s current answer to JVM cold start) is also an Oracle product. Hosting on Rust means hosting on a language governed by a nonprofit, with no licensing drama and no corporate owner to answer to.

Where Clofer would be useful

Data Science and Machine Learning

Clojure has always had a natural affinity for data. Its core abstractions — immutable data structures, lazy sequences, the sequence abstraction — map beautifully onto the kind of data transformation pipelines that data science is built on. Libraries like clojure.data and the broader data-oriented programming philosophy make Clojure genuinely pleasant for exploratory data work.

The problem is the JVM. In data science, you often want to run models at the edge, inside a browser, on a small device, or as a lightweight CLI tool that processes a CSV and exits. The JVM’s memory and startup overhead make all of that awkward.

Clofer on Rust changes the equation. Rust has a growing and serious ML ecosystem: Candle (HuggingFace’s ML framework written in pure Rust with GPU support) and Burn (a deep learning framework with multiple backends) are both gaining traction fast. Rust also has solid bindings to CUDA for NVIDIA GPUs, and wgpu for cross-platform GPU compute that works on Vulkan, Metal, DirectX, and even WebAssembly.

Imagine writing data pipelines in Clojure’s expressive, REPL-driven style — and having them run with Rust’s performance and memory efficiency, with access to GPU acceleration underneath. That’s not science fiction; it’s the direction Clofer points toward.

WebAssembly

WebAssembly is one of the most exciting deployment targets in software right now — and one where Clojure is currently underserved.

ClojureScript gets you Clojure in the browser, but via transpilation to JavaScript. It works well, but it inherits JavaScript’s runtime, JavaScript’s performance characteristics, and the complexity of the JS toolchain.

Rust compiles to WebAssembly cleanly and natively. A Clofer that inherits Rust’s WASM story could give you Clojure running directly in the browser as a native binary — faster than ClojureScript, with a smaller footprint, and without any JavaScript dependency. The same Clofer code could run on your server, your CLI, and inside a browser tab.

This matters beyond the browser too. WASM is increasingly used as a sandboxed execution environment on the server side (Cloudflare Workers, Fastly Compute, and others use it). Clofer could make Clojure a first-class citizen in that world.

Embedded Systems

This is perhaps the most dramatic frontier Clofer opens up.

Clojure has never been able to run on microcontrollers. The JVM is simply too heavy — it needs megabytes of RAM and a full operating system. Racket, despite its elegance, faces similar constraints. The Lisp family has largely been locked out of the embedded world.

Rust changed the story for systems programmers. It already runs on ARM Cortex-M, RISC-V, ESP32, and dozens of other embedded targets — without an operating system, with deterministic memory, and with a runtime measured in kilobytes. It has become the language of choice for serious embedded work precisely because it gives you C-level control with modern safety guarantees.

Clofer, built on Rust, could inherit all of that. A Clojure that compiles down to a tight native binary with no GC, no JVM, and no OS dependency could run on the same microcontrollers that Rust already targets. That would be genuinely unprecedented — a Lisp-family language with Clojure’s elegant data model running on an ESP32 or an ARM Cortex-M4.

The embedded world is crying out for higher-level, more expressive languages that don’t sacrifice performance or determinism¹. Rust is filling that gap for systems programmers. Clofer could fill it for the functional programming community.

What’s being built, and what it’ll take

Implementing a language is genuinely hard. Clojure’s dynamic nature is philosophically at odds with how Rust works — every step forward requires navigating that tension. The existing ClojureRS project (the closest precedent) stalled partly because of this: Rust’s static, compile-time-verified nature resists the kind of runtime reflection Clojure relies on.

The roadmap, roughly:

1. Learn Rust deeply — ownership, enums, traits, the borrow checker
2. Understand interpreter and compiler theory — parsing, evaluation, persistent data structures
3. Study Clojure’s internals — how namespaces, vars, macros, and STM actually work
4. Start small — a reader, an evaluator, a REPL

It’s a multi-year undertaking, honestly. But that’s also what makes it interesting.

The biggest gift to the world might not be the runtime characteristics at all. It might be proving that a beautiful, expressive Lisp can exist without a managed runtime.

Follow along

I will be sharing the journey here—what I’m learning about Clojure, what I’m learning about Rust, where the project hits walls, and what it feels like to explore a problem this large with no guarantee of success.

The project is called Clofer. Say it like Clojure’s sibling. Because that’s what it’s trying to become.

Foot Notes