Clj.rs – a Clojure dialect implemented in Rust (clj.rs)

111 pointsby simonpure4 days ago43 comments

vaylian 3 hours ago

One of the killer features of Clojure is it's seamless interop with the host platform. On the JVM you do something like

(Integer/parseInt my-variable); this calls Integer.parseInt(my_variable) in Java-land

I tried to find examples for how to call Rust code and the best I could find is:

https://github.com/csm/clojurust/blob/b847a29b46e2b6b3fbe624...

It looks like you need to do a lot of leg work to introduce Rust functions into Clojure namespaces. I guess there is no way around it and this is not a criticism of clj.rs. But it doesn't seem to be as seamless as on the JVM.

JavierFlores09 5 hours ago

Has Clojure become the new base for Lisp-like languages? What does it got going for it that people seem to want its specific flavor of lisp? Just asking since I've also seen the Clojure talk about Jank[1] recently and it has gotten me interested.

1: https://www.youtube.com/watch?v=tHgApFhevrQ

neutronicus 5 hours ago

Hash table literals.

Also, living on a host language has always been part of its ethos. So if you want to be Lisp on C++ or Lisp on Rust, you’re going to be more ideologically aligned with the Clojure crowd than the Common Lisp crowd who pinch their nose and say ALGOL when you mention either.

skydhash 4 hours ago

SBCL is written in C and have FFI baked in

http://www.lichteblau.com/sbcl/doc/manual/sbcl/Foreign-Funct...

Maybe it’s too much work to write a full lisp vm in another language when it’s easier to write a loader.

pjmlp an hour ago

Nowadays, historically Lisps have had the primitive forms written in Assembly and everything else bootstrap.

stassats 33 minutes ago

> SBCL is written in C

That's not quite right.

CountVonGuetzli 4 hours ago

Coming from Ruby, wanting to learn a Lisp, there are so many things in Clojure that make the language much easier for me to understand, compare to other Lisps. Simple things like first/rest vs car/cdr make it much more ergonomic and easy to grok, IMHO.

neutronicus 2 hours ago

Yeah I alluded to this in my comment, but I think the dict literals just make for a much easier on ramp for someone familiar with Python or JS (or JSON, which is increasingly unavoidable for even C++ devs like me).

hardwaresofton 3 hours ago

Nothing will ever be a base for lisps because theyre too malleable and the temptation ro create your own is too high

Anyway my recent favorite is Carp:

https://github.com/carp-lang/Carp

Serious projects in it? Zero

arikrahman 2 hours ago

Same, I needed a Lisp that was typed for the AI era where Clojure's dynamism didn't fit the bill. Carp was a perfect fit, and I managed to create a few projects with the help of Deepseek

cfiggers 2 hours ago

All Clojures are Lisps, but not all Lisps are Clojures. :)

netbioserror 2 hours ago

It's immutable, has bracket syntax for data structures, and most of its standard library has very sensible naming and nil-sentinel conventions. The result is that it's astonishingly easy to read and write. The data structure sharing under the hood also keeps it performant. Finding and obtaining packages with its build systems is also easy.

Scheme gets close but has some odd naming conventions and completely wild conventions for packages (SFRI, etc). CL's entire library is full of incredibly odd names first established at the very advent of computing. Using it can be...dense. And inconsistent, since it's not purely functional and has no dedicated data structure syntax.

Dansvidania 2 hours ago

the data structure literals are really pleasant to work with, and oh how I miss get-in and update-in in every other language (with all the ecosystem of functions that follow that pattern and are built to work with it)

pjmlp an hour ago

The ecosystem of Java, .NET and the Web, and contrary to other guest programming language communities, they embrace their host platform instead of downplaying it, and talking about replacing it.

As such you get all the nice stuff that has made Lisp a great language, plus access to modern libraries.

Note that since Common Lisp there has not been another standard, and in what concerns Scheme, Dr Raket is more relevant. Also R7rs Large has been hanging on for years now.

tux 6 hours ago

Why not name it “Cloju.rs” instead? :-)

imafish 6 hours ago

came here to write exactly that xD

xnfra 3 hours ago

The only thing I know about Clojure is Walmart used it to rewrite their entire inventory system.

jiehong 7 hours ago

Nice, but what are the non goals?

Except maybe the compilation to native binary, this is closer to clojurescript than clojure I suppose ?

How about a comparison with Jank?

arikrahman 2 hours ago

Love to see more Clojure dialects taking fruit. Jank is very promising for C++ and now we have the Rust complement

andersmurphy 4 hours ago

Claude sure is busy these days.

agumonkey 3 hours ago

'man' of the year

pjmlp an hour ago

Which is why when I see it on the contributions list, I close the browser tab right away.

It is like someone talking about culinary recipes, while leaving the frozen food boxes visible to the audience.

forgotpwd16 an hour ago

Many projects that'ld have found cool in the past, now have me hardly care about them. If anything, see them as token pit.

andersmurphy 10 minutes ago

Yeah but what's even sadder is projects like this sometimes end up getting open source funding from the community. Which just means money getting used to pay for claude subscription. Paying claude to give you stolen content to then deprive other non LLM projects from funding. Basically stealing from the community twice.

mono442 3 hours ago

It's vibecoded which makes it unlikely it has been actually tested well.

sshine 7 hours ago

Cool.

I'm already a big fan of the scheme-rs crate.

I use it any time I need a dynamic scripting language.

It allows for more flexible hot-reloading of parts of a program.

I don't personally have any Clojure interop holes that need filling.

But I can imagine a future where one moves partially away from the JVM if e.g. faster starts or leaner container images are desired.

benrutter 6 hours ago

I love scheme and rust but somehow did not know about scheme-rs! Looks like such a good project, thanks for the recommendation!

petre 4 hours ago

Any advantages over steel?

https://github.com/mattwparas/steel

rfgplk 5 hours ago

I'm working on something similar.

My guess is, within the next 3-5 years, most ALGOL descendant languages will become obsolete, and S-exp based Lisp dialects will take over. Objectively superior.

Behold a native kernel, no inline asm or linker scripts, of any kind. The full compiler pipeline is controllable through the compiler (you can arbitrarily target, devise, or enable/disable various optimization passes, for instance you can enable LICM at will). Also has a hard 1:1 correspondence to C/C++/Rust/adding more languages soon.

   ;; GNU multiboot kernel
   (image (target x86-64) (origin 0x100000) (entry "boot32")
     (section ".multiboot" (align 4) (keep))
     (section ".bss" (align 4096) (zero))
     (stack "bootstrap" 16384) (stack "kernel" 32768)
     (assert (<= (address "kernel.end") 0x40000000) "early memory must fit the first GiB identity map"))
   
   (static header (Array u32 8)
     (declare (section ".multiboot") (used) (link-name "multiboot_header"))
     (arr (0x1badb002 0x10003 0xe4514ffb
           (link u32 (address "multiboot_header")) (link u32 (origin))
           (link u32 (+ (origin) (image-size))) (link u32 (+ (origin) (image-size)))
           (link u32 (address "boot32")))))
   (static gdt (Array u64 3) (declare (aligned 8) (link-name "boot_gdt"))
     (arr (0 0x00af9a000000ffff 0x00cf92000000ffff)))
   (static pml4 (Array u64 512) (declare (mutable) (aligned 4096) (link-name "boot_pml4")))
   (static pdpt (Array u64 512) (declare (mutable) (aligned 4096) (link-name "boot_pdpt")))
   (static pages (Array u64 512) (declare (mutable) (aligned 4096) (link-name "boot_pages")))
   
   (fn prepare-paging ()
     (declare (mode protected32) (noinline))
     (dotimes (i 512)
       (at pml4 i (->u64 0)) (at pdpt i (->u64 0))
       (at pages i (| (* (->u64 i) 0x200000) 0x83)))
     (at pml4 0 (| (link u64 (address "boot_pdpt")) 3))
     (at pdpt 0 (| (link u64 (address "boot_pages")) 3))
     (unsafe
       (x86::write-cr 'cr3 (link u64 (address "boot_pml4")))
       (x86::write-cr 'cr4 (| (x86::read-cr 'cr4) 32))
       (x86::write-msr 0xc0000080 (| (x86::read-msr 0xc0000080) 256))
       (x86::load-gdt (link VirtAddr (address "boot_gdt")) 23)))

   (fn show-greeting ()
     (unsafe
       (auto video (i->ptr (Volatile u16) 0xb8000))
       (dotimes (i 2000) (at* video i (+ 0x5725 (->u16 i))))
       (auto greeting ":d")
       (dotimes (i (size greeting))
          (auto byte (->u8 (at greeting i)))
         (at* video i (| 0x0f00 (->u16 byte)))
         (x86::out8 0xe9 byte))
       (x86::out8 0xe9 10)))

   (boot-entry boot32 (mode protected32)
     (handoff (magic eax u32) (information ebx PhysAddr))
     (with-stack "bootstrap"
       (prepare-paging)
       (unsafe
         (x86::enter-long-mode 'kernel64 8 magic information (link u64 0x123456789abcdef0)))))

   (boot-entry kernel64 (mode long64)
     (handoff (magic rdi u32) (information rsi PhysAddr) (cookie r12 u64))
     (with-stack "kernel"
       (unsafe
         (x86::write-segment 'ds 16) (x86::write-segment 'es 16) (x86::write-segment 'ss 16)
         (auto valid (and (= magic (->u32 0x2badb002)) (> (address-bits information) 0)
                          (= cookie (->u64 0x123456789abcdef0))
                          (= (& (x86::read-cr 'cr0) 0x80000001) 0x80000001)
                          (= (& (x86::read-msr 0xc0000080) 0x500) 0x500)))
         (if valid (show-greeting)
           (progn (x86::out8 0xe9 70) (x86::out8 0xe9 10))))))

neutronicus 5 hours ago

Curious why you’re so bullish on S-Expressions now of all times.

It seems like the idea of the macro, and more generally of expressing code succinctly, is the closest to obsolete in my memory?

The other half of the Lisp sales pitch (image based development, constantly inspect state, hot swap code, REPL, etc) seems like what has retained currency in the LLM age.

frje1400 3 hours ago

> It seems like the idea of the macro, and more generally of expressing code succinctly, is the closest to obsolete in my memory?

That seems true in a world where we completely stop looking at code. Right now my reality is giant verbose PRs written by agents in Java, and it sucks to review.

neutronicus 2 hours ago

Yeah, I mean this is somewhat compelling, although the old arguments people brought out (macros are obfuscatory) seem to grow more teeth if agents are writing the macros.

So I guess the idea is tastemaker humans spend all their time coming up with sweet macros and telling agents to refactor the ever shrinking code base.

But even still I think the main argument for S-Expressions (it’s easiest for humans to create DSLs by working on serialized AST) has become weaker. If DSLs are the best way to make a code base readable, you can now have your agent create one with whatever syntax you like!

rgoulter 2 hours ago

> If DSLs are the best way to make a code base readable, you can now have your agent create one with whatever syntax you like!

I think these things are going to be true:

- For a specific well-defined coding task, an LLM coding agent will be able to execute it quicker than humans, regardless of how it does it.

- Codebases which are well organised will be easier for an LLM to manipulate than codebases which are obscure and surprising.

I mean.. I think it's plausible that something like "lisp makes DSLs easy, DSLs are a great way to arrange code" is especially true with LLMs; but I'd also think you'd need to know when to use (& when to not use) DSLs to get effective results from this.

Whereas, say, you could have the LLM come up with a DSL in a way which is high friction for the LLM to do it ... but, you'd get the result a bit slower, & maybe worse.

ianjbutler an hour ago

Thinking along these lines myself lately. Even better than dsls is dsls directly descended from recognizable formalisms, which achieves compression for humans and agents at the same time, and is even more effective than any other kind of dsl’s at restricting the bad kind of ai “creativity”.

I’ve been experimenting with stuff like “this project is a Kahn process network, every change is strict conformer to that model, add features only by adding nodes”. As a bonus if you’re strict then porting the specific implementation to a new language should be easy.

To me stuff like this feels like the future of programming.. details don’t matter but design language does. not leet code of fancy data structures from scratch but at least a basic familiarity with LOTS of them, a working knowledge of vast zoos of expressive patterns and automata, etc.

embedding-shape 3 hours ago

> It seems like the idea of the macro, and more generally of expressing code succinctly, is the closest to obsolete in my memory?

Seems more important than ever? Every model degrades the more context you use, programs that can be described more succinctly will be better made, at least when using LLMs to create these, as it's much easier to fit more "meat" per token.

I'm on the same "S-Expressions taking over is inevitable" but to be fair, I've been on this train for the last decade so maybe I'm slightly biased.

neutronicus 3 hours ago

That’s a plausible story, but doesn’t seem to bear out in terms of models being amazing at Lisp. Like, Sonnet 4.5 was writing me emacs Lisp with unbalanced parentheses.

I don’t really have faith that I could write macros of such incredible brilliance that it would outweigh the models’ facility with Python.

sham1 3 hours ago

This does look interesting, although I did get a chuckle from the "no inline assembler" claim and then seeing x86 intrinsics in the source for seeing some special registers like the segment registers, GDTP, setting IO ports, and some such. Those are of course necessary, but at least in terms of portability, they're not that far off from inline assembler.

From a quick glance over your example, it looks like a hodgepodge of Scheme, Clojure, and Common Lisp with some Rust-y constructs in it. If you don't mind elaborating, why not take some existing "embedded" dialect like Pre-Scheme and compile that? Because currently this looks a lot more like Rust-with-parenthesis rather than a Lisp. Of course if that's the goal then that's fine, but I'd like to hear some elaboration on that.

forgotpwd16 an hour ago

>My guess is, within the next 3-5 years, most ALGOL descendant languages will become obsolete, and S-exp based Lisp dialects will take over.

In AI-driven world, programming languages have become more of a hobby, especially in regards to syntax/semantics. Importance is now mostly solely on tooling quality features and compiler-enforced guarantees. Rust has always been popular "written in" target, even more now, and probably the last language shift for a long time, offering compiler-time memory safety, excellent compile messages, packaging/deployment ergonomics, etc.

My guess is, your language (as is the submitted one) compiler/tooling is written in Rust and made by/in-assistance-with AI, probably Claude.

lightningspirit 5 hours ago

I expect this to take over within the next couple of years. Great job!

pseudony 5 hours ago

Take over what, exactly? The java ecosystem version? The javascript ecosystem version ? The c++, clojure-like dialect ?