Pretty nifty. As of now, the code doesn't compile: there's some stray "span" stuff in codegen.rs[1], and it's trying to format `Warning` which doesn't implement `Display` in main.rs[2].

Fixing these, it runs mostly as advertised, but it seems to assume that one-letter types are always generic parameters, so it's impossible to (for example) generate this:

    struct X;
    enum A {
        P(X),
        Q
    }

Trying this:

    (struct X)
    (enum A (P X) Q)

produces this:

    struct X;
    enum A<P, X> { Q }

while using a multi-letter type like `String`:

    (enum A (P String) Q)

produces the expected:

    enum A { P(String), Q }

One way to solve this would be to always require the generic annotation, and let it be empty when there are no generics, but when I tried that it did something weird:

    (struct X)
    (enum A () (P X) Q)

produces:

    struct X;
    enum A {
        _ /* List([], Some(Span { start: 54, end: 56 })) */,
        P(X),
        Q
    }

I have no idea where the `_` and the comment came from.

[1] https://github.com/ThatXliner/rust-but-lisp/blob/70c51a107b2...

[2] https://github.com/ThatXliner/rust-but-lisp/blob/70c51a107b2...

I think some comments are missing the upside of it being precisely Rust, without any new semantics. If you want lisp that compiles to machine code, Common Lisp can get reasonably efficient. The purpose of bringing Rust into it is to surface Rust-specific semantics -- which many people quite like!

Claims to have all the syntax covered, but not a single example of specifying lifetimes or the turbofish, some of the trickiest rust syntax

It seems like this is more like writing Rust in an s-expression syntax instead of having a proper lisp dialect that compiles to Rust, which is cool I guess but not very interesting.

It's quite weird-looking for someone who's done any amount of lisp programming.

Readers may enjoy my lisp, Loon, which takes heavy inspiration from Rust https://loonlang.com/guide/ownership

I’ve seen this done with C as well.

https://www.eriksvedang.com/carp

https://github.com/tomhrr/dale

> ((. dx powf 2.0) + (. dy powf 2.0)) sqrt))

I don't know what this is, but clearly not Lisp...

So if I wanted to actually use this and I write some rust-but-lisp code and there's a compile error, will it show me a nice error message with an arrow pointing to where the error happened in my lisp code?

Can I use the amazing `rust-analyzer` LSP to get cool IDE features?

I suspect the answer is no, but these might be good further prompts to use.

Should be named "Rutht"

Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:[1][2]

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Maybe we should one day include Golang or Rust to it

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Reminds me of when I brainstormed an S-expression-based alternative syntax for Rust in the comments on an article about Rust's syntax: <https://news.ycombinator.com/item?id=41399712>.

This is probably what Rust's internal ASTs look like. But why would you want to input programs as ASTs?

How do you change the syntax to eliminate reverse compatibility? I guess you could change the names of most key functions between releases. But to be compatible with rust you would need to make breaking changes every release.

How is pure unbridled AI slop like this making the front page? Voting rings?

I don't even feel bad saying this because clearly OP is just the front for Claude here.

I don't understand why this had to be LLM generated. S-expression syntax parsers are not hard to write. That's rather much the point of S-expressions.

"no runtime, no GC, just" I am BEGGING every project to not have this LLMism in their docs.

It reads as No X no Y just slop to me every time.

does there exist something that can do the opposite?

some pre-processor that "compiles into rust" from less awful syntax?

Unfortunately, given the clear LLM basis of this project, s-expressions aren't a great choice. I've found coding agents struggle really hard with s-expression parentheses matching.

Much better to give them something more M-expr styled, I think a grammar that is LL(1) is probably helpful in that regard.

Basically the more you can piggyback on the training data depth for algol-style and pythonic languages the better.

Anyone working on something similar that compiles to go?

I actually like it better than plain Rust…

I think this misses the point of LISP macros. LISP macros are just functions written in LISP, so here macros need to be functions written in Rust-but-LISP, but it is not so. In fact, I think this macro language lacks conditionals, so it’s not even Turing-complete.

> compiles directly to Rust — no runtime, no GC, just (s-expr → .rs → binary).

Can we please write our own READMEs before posting to HN?

"Lust", or "Risp"?

For everyone who is shaming on the project for "not implementing enough," then you can definitely help me with it.

For everyone who is shaming on the project for being "LLM slop," sure but that's the reason why something like this can exist in the first place. The point isn't to be a finished, production-ready product. The point is to be an interesting work, and just a sly bit silly

And for why?

And if you like Lisp and ownership, there's also Carp [1]. It doesn't mimic Rust's features and naming schemes though.

Carp is about 10 years old and has some cool demo's (like SDL for gamedev).

> The key features of Carp are the following:

> * Automatic and deterministic memory management (no garbage collector or VM)

> * Inferred static types for great speed and reliability

> * Ownership tracking enables a functional programming style while still using mutation of cache-friendly data structures under the hood

> * No hidden performance penalties – allocation and copying are explicit > * Straightforward integration with existing C code

> * Lisp macros, compile time scripting and a helpful REPL

[1]: https://github.com/carp-lang/Carp

I like the ubiquitous type inference. It reminds me a bit of ELSA for Emacs Lisp: https://github.com/emacs-elsa/Elsa. In particular, type aware macros have been on my wishlist forever: there's no good reason I shouldn't be able to write, e.g. an elisp or CL/SBCL compiler-macro that specializes an operation based on its inferred type. In normal lisps, it's hard to get even the declared types.

That said, I wish that part of Loon were less coupled to the allocation model though. What made you opt for mandatory manual memory management in an otherwise high-level language? And effects?

There are two things common in language design that, honestly, strike me as unnecessary:

1. manual allocation and lifetime stacking, and

2. algebraic effects.

On 1: I think we often conflate the benefits of Rust-style mutability-xor-aliased reference discipline with the benefits of using literal malloc and free. You can achieve the former without necessitating the latter, and I think it leads to a nicer language experience.

It's not just true that GC "comes with latency spikes, higher memory usage, and unpredictable pauses" in any meaningful way with modern implementations of the concept. If anything, it leads to more consistent latency (no synchronous Drop of huge trees at unpredictable times) and better memory use (because good GCs use compressed pointers and compaction).

On 2: I get non-algebraic effects for delimited continuations. But lately I've seen people using non-flow-magical effects for everything. If you need to talk to a database, pick a database interface and pass an object implementing the interface to the code that needs it. Effects do basically the same thing, but implicitly.

Agreed, a Lisp built around the concept of ownership is much more interesting than just a way to write Rust via S-expressions.

How does ownership work within the Lisp tree structure?, What is the difference between ownership on this setting and ARC?

I like it but confusing that there's also a similar but different loonlang.org.

That page is beautiful! What ssg / theme are you using to build it?

Honestly, that's very cool

That was basically my intent with this project, but I took the laziest way to get there lol