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.
rogerhey 22 hours ago [-]
spot on! we evaluated and chose regular Clojure for this reason. looking at jank now it seems very interesting for the interop. also I use a fair bit of Babashka because I like how fast it starts (good for clis and tools for agents).
JavierFlores09 1 days 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.
My first lisp was Clojure. Was skeptical but willing to try. Within two days I was writing a new component for our stack wrapping parts of the Aws sdk to access sqs (years ago).
Since looped around and had semi serious spells of Racket (scheme++; one could say) and Common lisp - purchasing stacks of books along the way.
For me - Clojure was THE language that really taught me functional programming - there really isn’t anything mutable without significant contortions.
It is also just a really good standard library and full of interesting concepts like specs (as opposed to types), transducers and such.
I would say that common lisp still has some interesting, unique features like conditions, which is essentially what exceptions SHOULD have been. But Clojure has a LOT of bang for buck.
Finally, I would swear my most intelligent, high impact code has been written in clojure. There is something to be said for the decomposition of problems with higher-order functions and immutable data structures and a live REPL.
pjmlp 1 days 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.
CountVonGuetzli 1 days 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.
vindarel 19 hours ago [-]
There's first, second... tenth and rest in CL too. My 0.0002c.
The convention is to use car and cdr with cons cell structures that are not lists.
neutronicus 1 days 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).
cfiggers 1 days ago [-]
All Clojures are Lisps, but not all Lisps are Clojures. :)
hardwaresofton 1 days ago [-]
Nothing will ever be a base for lisps because theyre too malleable and the temptation ro create your own is too high
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
Hammershaft 23 hours ago [-]
Clojure's data structure design & concurrency model is particularly great, and the host interop opens up options for pragmatic development.
Macros are less ergonomic than other lisps.
bjoli 23 hours ago [-]
I am just sad core.async is just the same old CSP.
I want to scream every time I have to implement nacks in CSP. It has to be domain specific every time, since there are no first class events.
I do agree that clojure gets a lot right (like an actually well integrated STM layer), the choice to go with CSP seems like a missed opportunity.
netbioserror 1 days 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 1 days 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)
bjoli 23 hours ago [-]
Aren't get-in and update-in a poor man's lenses? I find similar abstractions in most functional languages.
neutronicus 1 days 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.
Maybe it’s too much work to write a full lisp vm in another language when it’s easier to write a loader.
stassats 1 days ago [-]
> SBCL is written in C
That's not quite right.
pjmlp 1 days ago [-]
Nowadays, historically Lisps have had the primitive forms written in Assembly and everything else bootstrap.
whalesalad 23 hours ago [-]
clojure is the best lisp by far
caseym831 18 hours ago [-]
Hi! Author of the project here. I thought I could give some background on the project.
I started this when I was looking for a job in early 2026. Vibe coding was coming up at the time, and my initial work was partially hand-coded and partially given to Claude. The pivot between hand coding and full agent-based coding really took off during that time. I did get a job a few months into this year, and I've been hacking on this in the background when I can. The recent work has definitely been done by LLMs instead of me, but that's also because I have a ton of kids and vibing something on my phone is sometimes the only way I can do it. I do that with $20 per month subscriptions anyway (Claude & ChatGPT), and I'll gladly have them subsidize the compute work for my personal project, while it lasts.
Some of the internals might be a horror show, I'm willing to say. I have not looked that closely, though I'm trying to keep it headed in a reasonable direction. I'm working to understand my life now as a SW engineer as much as everyone else.
Why do it? I loved programming Clojure, and liked Rust when I was learning it early this year. I decided to just try it, and I've enjoyed getting it to a mostly-compatible position. Also Rich had made a post on LinkedIn about how token-efficient Clojure is, and thought a Clojure/Lisp could be a great language for AI assisted code generation. That said I don't know what it'll turn into, I'm just having fun with it.
munro 23 hours ago [-]
When I was using Clojure, I loved how intelligently the stdlib was design. It felt like one person combed over everything in one sitting to make sure naming was consistent, followed conventions, no two ways to do the same thing, and could be composed together, really beautiful stuff.
I do think no types is why I never reach for it. I just love typing in Rust & TypeScript so much. But at the time of Clojure, those languages didn't exist, JS/Ruby/Python/Java/C++ were all still very popular, and typing made easy hadn't caught on yet. ;)
tux 1 days ago [-]
Why not name it “Cloju.rs” instead? :-)
imafish 1 days ago [-]
came here to write exactly that xD
xnfra 1 days ago [-]
The only thing I know about Clojure is Walmart used it to rewrite their entire inventory system.
iLemming 20 hours ago [-]
Also the biggest digital world bank built on it. Afaik Apple's app store payments system uses it. Cisco's cybersec layer CTIM/CTIA (Cisco Threat Inteligence Model and API) and project IROH (Incident Response Orchestration Hub) built on it. Netflix uses it. NASA has some of it. CircleCI's backend built on it, frontend initially was also Clojurescript. Docker, Metabase, Qlik, Funding Circle, Splash Financial, Rate.com, etc. Tons of Europeans startups using it.
forgotpwd16 1 days ago [-]
Didn't know this. What they used before and why the decision? An article/presentation by the devs that worked on this will be interesting.
TIL Walmart Labs was so into clojure. I would really like to know to what degree they still are — does datomic have Walmart as a customer?
embedding-shape 1 days ago [-]
> We try to avoid condescending put downs here.
I'm guessing that's why we nowadays have Facebook-like comments responding to a title with "I don't actually have any experience with the subject, and never heard about that, wow!" and similar.
Every single Clojure submission inevitably have someone mention Walmart. Cool, but do we need to add that to every submission, unless there is something new about it, or something we could actually discuss? And even more important, could those things be said by the people who actually have knowledge about it?
I'm not in C# submissions sharing what I know or don't know about C#, because I'm not in the ecosystem, and it doesn't make sense to write comments about stuff even I know I don't know about, unless I'm asking about something or similar. Like what's the point even?
Dansvidania 1 days ago [-]
gotta love that trademark HN snark
jiehong 1 days 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?
slifin 10 hours ago [-]
Clojure's Flowstorm should be the minimal baseline to anything of mild complexity in any language/project
It's the primitive required for Bret Victor's seeing spaces talk and the ideas are still ignored some 15+ years later
arikrahman 1 days ago [-]
Love to see more Clojure dialects taking fruit. Jank is very promising for C++ and now we have the Rust complement
mateuszf 1 days ago [-]
Babashka is amazing, I recommend you check it if you haven't yet.
xedrac 17 hours ago [-]
I think the point of something like Jank or Clj.rs is less about the native compilation aspect (we already have that with Babashka), and more about the seamless interop with the host language. Babashka doesn't help with that.
andersmurphy 1 days ago [-]
Claude sure is busy these days.
forgotpwd16 1 days 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 1 days 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.
pjmlp 1 days 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.
agumonkey 1 days ago [-]
'man' of the year
sshine 1 days 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 1 days ago [-]
I love scheme and rust but somehow did not know about scheme-rs! Looks like such a good project, thanks for the recommendation!
It needs a much better name than Clj.rs. Try 'rusteze'.
lilactown 24 hours ago [-]
REPL on the home page fails in safari:
panicked at /rustc/58cf8f9c35b355199727627d07ae34a4e2846d67/library/std/src/sys/time/unsupported.rs:13:9:
time not implemented on this platform
rfgplk 1 days 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.
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 1 days 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.
olmo23 5 hours ago [-]
> I'm working on something similar.
Is there any place we can follow along because this looks cool!
neutronicus 1 days 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.
clx75 1 days ago [-]
If you write a compiler for a low level Algol-family language in a LISP, then LISP's homoiconic nature makes certain patterns possible which do not come so easy in other languages.
The compiler becomes a library in the host language. As you can use the syntax of the host language for the compiled language, you can create host-side defining forms like (define-compiled-function [NAME PARAMS & BODY]) which parse the body of the compiled function into an AST and bind the resulting data structure into a namespaced variable of the host language. This way you can rely on the host's namespacing mechanisms and probably reuse even its packaging and code distribution model for your low level language.
Another interesting feature which just "falls out" is compiler macros: you can use ordinary functions of the host language as macros (code transformers) in the compiled language.
Then you can write a lowering function which takes one of these AST vars, walks its call graph, resolves references and lowers the whole thing into your target language, be it Python, Go, LLVM IR, assembly, whatever.
If you pass a context to your lowering function which binds settings dynamically like target arch, word size, C calling convention, etc. then the code generators can emit the corresponding lowerings and you get portability using the dispatch/polymorphism facilities of the host language.
This way you can push most of the complexity of the language to the LISP side. Basically you get a programmable compiler for your low level language.
I expect to see a lot more examples of this pattern in the coming years.
neutronicus 23 hours ago [-]
That sounds pretty juicy, but “implementing a C++ compiler in Lisp” is a pretty big squeeze.
frje1400 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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.
KingMob 15 hours ago [-]
Token efficiency is good, but in practice, model familiarity is more important.
Look at what happened with TOON. They came up with a format meant to replace JSON for agents, but despite being way more succinct, its novelty meant that LLMs spent just as many tokens correcting mistakes while using it.
TBF, that was several months ago, an eternity in LLM time. Someone should rerun those language studies, it's possible the SOTA has changed.
neutronicus 1 days 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.
jazzypants 1 days ago [-]
[dead]
thisisauserid 1 days ago [-]
I always assumed the j on Clojure was a nod to the JVM but now that wouldn't work.
iLemming 20 hours ago [-]
Clojure CLR is an official port since forever. Squint, SCI (nbb), Clojerl, ClojureDart, Jolt, Jank ... none of them tied to JVM. Not to mention Clojure-like Lisps - Fennel, Janet, Carp, Hy.
lightningspirit 1 days ago [-]
I expect this to take over within the next couple of years. Great job!
pseudony 1 days ago [-]
Take over what, exactly?
The java ecosystem version? The javascript ecosystem version ? The c++, clojure-like dialect ?
pmbauer 1 days ago [-]
Some vibe slopped lisp where the maintainer doesn't have the technical skills to achieve sustained excellence without consulting an LLM every other minute and almost certainly doesn't have the social juice to evangelize Lisp? That's taking over? Over what?
throwawaygod 22 hours ago [-]
Little harsh on the maintainer. But say if the author has the technical chops for creating successful? language but if the project is still vibecoded, will that be acceptable? Should we be excited of such projects?
pmbauer 16 hours ago [-]
> The recent work has definitely been done by LLMs instead of me, > [...] Some of the internals might be a horror show, I'm willing to say. I have not looked that closely
You tell me. Should we be excited?
mono442 1 days ago [-]
It's vibecoded which makes it unlikely it has been actually tested well.
(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.
1: https://www.youtube.com/watch?v=tHgApFhevrQ
Since looped around and had semi serious spells of Racket (scheme++; one could say) and Common lisp - purchasing stacks of books along the way.
For me - Clojure was THE language that really taught me functional programming - there really isn’t anything mutable without significant contortions.
It is also just a really good standard library and full of interesting concepts like specs (as opposed to types), transducers and such.
I would say that common lisp still has some interesting, unique features like conditions, which is essentially what exceptions SHOULD have been. But Clojure has a LOT of bang for buck.
Finally, I would swear my most intelligent, high impact code has been written in clojure. There is something to be said for the decomposition of problems with higher-order functions and immutable data structures and a live REPL.
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.
The convention is to use car and cdr with cons cell structures that are not lists.
Anyway my recent favorite is Carp:
https://github.com/carp-lang/Carp
Serious projects in it? Zero
Macros are less ergonomic than other lisps.
I want to scream every time I have to implement nacks in CSP. It has to be domain specific every time, since there are no first class events.
I do agree that clojure gets a lot right (like an actually well integrated STM layer), the choice to go with CSP seems like a missed opportunity.
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.
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.
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.
That's not quite right.
I started this when I was looking for a job in early 2026. Vibe coding was coming up at the time, and my initial work was partially hand-coded and partially given to Claude. The pivot between hand coding and full agent-based coding really took off during that time. I did get a job a few months into this year, and I've been hacking on this in the background when I can. The recent work has definitely been done by LLMs instead of me, but that's also because I have a ton of kids and vibing something on my phone is sometimes the only way I can do it. I do that with $20 per month subscriptions anyway (Claude & ChatGPT), and I'll gladly have them subsidize the compute work for my personal project, while it lasts.
Some of the internals might be a horror show, I'm willing to say. I have not looked that closely, though I'm trying to keep it headed in a reasonable direction. I'm working to understand my life now as a SW engineer as much as everyone else.
Why do it? I loved programming Clojure, and liked Rust when I was learning it early this year. I decided to just try it, and I've enjoyed getting it to a mostly-compatible position. Also Rich had made a post on LinkedIn about how token-efficient Clojure is, and thought a Clojure/Lisp could be a great language for AI assisted code generation. That said I don't know what it'll turn into, I'm just having fun with it.
I do think no types is why I never reach for it. I just love typing in Rust & TypeScript so much. But at the time of Clojure, those languages didn't exist, JS/Ruby/Python/Java/C++ were all still very popular, and typing made easy hadn't caught on yet. ;)
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
We try to avoid condescending put downs here.
With regards to walmarts adventures in clojure:
https://news.ycombinator.com/item?id=19728502
TIL Walmart Labs was so into clojure. I would really like to know to what degree they still are — does datomic have Walmart as a customer?
I'm guessing that's why we nowadays have Facebook-like comments responding to a title with "I don't actually have any experience with the subject, and never heard about that, wow!" and similar.
Every single Clojure submission inevitably have someone mention Walmart. Cool, but do we need to add that to every submission, unless there is something new about it, or something we could actually discuss? And even more important, could those things be said by the people who actually have knowledge about it?
I'm not in C# submissions sharing what I know or don't know about C#, because I'm not in the ecosystem, and it doesn't make sense to write comments about stuff even I know I don't know about, unless I'm asking about something or similar. Like what's the point even?
Except maybe the compilation to native binary, this is closer to clojurescript than clojure I suppose ?
How about a comparison with Jank?
It's the primitive required for Bret Victor's seeing spaces talk and the ideas are still ignored some 15+ years later
It is like someone talking about culinary recipes, while leaving the frozen food boxes visible to the audience.
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.
https://github.com/mattwparas/steel
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.
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.
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.
Is there any place we can follow along because this looks cool!
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.
The compiler becomes a library in the host language. As you can use the syntax of the host language for the compiled language, you can create host-side defining forms like (define-compiled-function [NAME PARAMS & BODY]) which parse the body of the compiled function into an AST and bind the resulting data structure into a namespaced variable of the host language. This way you can rely on the host's namespacing mechanisms and probably reuse even its packaging and code distribution model for your low level language.
Another interesting feature which just "falls out" is compiler macros: you can use ordinary functions of the host language as macros (code transformers) in the compiled language.
Then you can write a lowering function which takes one of these AST vars, walks its call graph, resolves references and lowers the whole thing into your target language, be it Python, Go, LLVM IR, assembly, whatever.
If you pass a context to your lowering function which binds settings dynamically like target arch, word size, C calling convention, etc. then the code generators can emit the corresponding lowerings and you get portability using the dispatch/polymorphism facilities of the host language.
This way you can push most of the complexity of the language to the LISP side. Basically you get a programmable compiler for your low level language.
I expect to see a lot more examples of this pattern in the coming years.
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.
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!
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.
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.
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.
Look at what happened with TOON. They came up with a format meant to replace JSON for agents, but despite being way more succinct, its novelty meant that LLMs spent just as many tokens correcting mistakes while using it.
TBF, that was several months ago, an eternity in LLM time. Someone should rerun those language studies, it's possible the SOTA has changed.
I don’t really have faith that I could write macros of such incredible brilliance that it would outweigh the models’ facility with Python.
You tell me. Should we be excited?