I really miss this book, PHP: The Complete Reference. When I read it, I picked up PHP in a jiffy.

Everything had complete examples. Whatever code that was newly added was highlighted and called out, and it was really easy to follow. This was before LLMs, and I think even before Stack Overflow became really popular.

Compared to PHP: The Complete Reference, the Rust book is no match. The Rust community doesn’t want beginners to learn Rust — it wants advanced programmers to learn Rust, which could even be fatal for the language in the long run.

So I am looking for new sources apart from the Rust book, and I have zeroed in on a freeCodeCamp video.

Maybe this video has a practical demonstration of how to code with Rust, and maybe, by watching the video and typing along side by side, I can learn Rust quicker.

So that’s about it for this week. Let me report back next week on what I’m up to. I also miss Clojure. Compared to Clojure, Rust is super difficult — you don’t have a REPL and all those things. I just really miss my Clojure projects, and I want to contribute to them because I love Clojure. Let’s see how things go, and let’s see if I forge ahead or give up. I don’t think I’ll give up before I write a Lisp interpreter in Rust. I really want to learn to write a compiler.

I have started learning Rust from The Book, currently I am reading The Slice Type. For some reason ownership did not look confusing to me, but references & borrowing did.

I learn a programming language by doing a lot of exercises. I will soon put a repo in Codeberg, where I will upload my Rust learnings. The Rust book seems to be a book written for people who already know other programming languages. I don’t think you should write a programming language book like that. It should be a book where anybody can pick it up — in plain natural language — and be able to understand it. If the Rust community doesn’t do it, I think a lot of people are going to avoid Rust. It’s the same with Clojure. Clojure has been dominated by people who are really experienced in the industry, and they don’t even bother about people who are starting with Clojure as their first programming language.

In fact, it’s the people who are already familiar with other programming languages that are the ones who are going to start with Clojure. I have never seen a total noob to programming pick up Clojure. Somehow the Clojure community seems to have turned a blind eye to this huge problem. They are happy the way they are.

Even though you have AI, you do need muscle memory to write good code. Or at least in today’s case, to check for improvements that could be made by A.I., and to find corrections in it without much effort. Mastery is very important.

Should I vlog or blog about Rust? I don’t know. I don’t have the bandwidth. I already have a channel called Clojure Diary where I vlog about Clojure. That was because I couldn’t find sufficient material that would help a beginner learn Clojure. I also write a book on Clojure, for almost the same reason. There aren’t many libre books on Clojure. Maybe the community is very small, so there aren’t many who will talk and write about it. This could be the result of the community never trying to promote Clojure as a beginner-friendly first programming language that one can learn.

Don’t Have Expectations

I want to tell the reader of this blog: please don’t have expectations. This is a highly ignorant guy, who is passionate, maybe foolhardy, and for some reason thinks he can host Clojure on top of Rust. It might never happen. At most, I think I can write a Lisp interpreter in Rust. Right now I have no idea how to create a compiler for Lisp using Rust. Compiling stuff to machine code, I feel is far difficult than interpreting stuff.

I do know that Build Your Own Lisp might be helpful. Right now I want to learn Rust, then use this book to build Lisp with Rust.

I’m determined to put just another foot forward, and I am dedicated enough to tell the world what step I have taken — that’s about it for now.

The Learning Path:

1. Rust (the big one)

This is the unavoidable foundation. Specifically you’d need to go beyond basics and get comfortable with:

• Ownership & borrowing deeply — not just the basics, but the tricky cases with recursive data structures (which a Lisp interpreter is full of)
• Enums & pattern matching — Clojure’s Value type is a big Rust enum, and you’ll live inside pattern matching
• Rc<T> / Arc<T> — ClojureRS uses reference counting for its values; understanding when to use which matters
• Traits — you’ll need these to implement Clojure’s protocols and interfaces in Rust
• Macros — both Rust macros (for reducing boilerplate) and eventually implementing Clojure macros on top

2. Interpreter / compiler theory

This is probably the second biggest gap. You’d need to understand:

• Parsing & lexing — turning Clojure text into an AST (s-expressions make this simpler than most languages actually)
• Evaluation models — how a tree-walking interpreter works, environments, scopes
• Tail call optimization — one of ClojureRS’s stated goals; non-trivial to implement
• Persistent data structures — Clojure’s immutable vectors, hashmaps, and lists are not trivial. Phil Bagwell’s Hash Array Mapped Trie (HAMT) is what real Clojure uses

3. Clojure internals

You’d benefit from understanding how the JVM Clojure actually works:

• How the reader/compiler pipeline works
• How namespaces, vars, and atoms are implemented
• How STM and concurrency primitives work under the hood
• Reading the original Java source of Clojure is actually enlightening

4. Lisp fundamentals

Since ClojureRS is a Lisp at heart:

• Understanding homoiconicity (code as data)
• How macroexpansion works
• How special forms differ from regular functions

Honest learning path

The Rust borrow checker will be the steepest wall. Budget real time for it — most developers need a few weeks before it clicks. But once it does, the rest becomes much more approachable.

Would you want to just experiment with it, or are you thinking of seriously reviving it?

A Note To The Reader

Dear readers, I never thought I will one day get the desire to port Clojure on top of Rust. I am not a computer science graduate; my ignorance is huge. This syllabus was charted by an LLM. So if you, the humans, can recommend corrections and suggestions, it would be really great.

I would also commit to posting an update here every week, and share it across Clojure channels. Some weeks, or even many weeks, I might not work, and I will post that I have not worked on this project. This project has generated interest amongst some people, and I feel it’s my duty to keep them posted — not just about my successes, but about my failures, laziness, inability, lack of interest, and possibly abandoning this project (if that ever happens).

One thing I can assure you is, I don’t give up that easy.

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