Show HN: Rust but Lisp (opens in new tab)

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

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.

> ((. 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.

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.

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

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.

Anyone working on something similar that compiles to go?

does there exist something that can do the opposite?

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

"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.

Should be named "Rutht"

"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

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.

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

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

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.

And for why?