This is probably what Rust's internal ASTs look like. But why would you want to input programs as ASTs?
so you can do the transformations (see the rlisp macro section)
Show HN: Rust but Lisp
21–30 of 79 posts
Re: Show HN: Rust but Lisp
#22This is probably what Rust's internal ASTs look like. But why would you want to input programs as ASTs?
so you can do the transformations (see the rlisp macro section)
Yes, but you could do the same by transforming Rust's ASTs. The only downside is that your input format is different from the format you are transforming. But the upside is that readability is much improved, which matters because code is typically read far more often than it is written.
Re: Show HN: Rust but Lisp
#23Readers may enjoy my lisp, Loon, which takes heavy inspiration from Rust https://loonlang.com/guide/ownership
Re: Show HN: Rust but Lisp
#24How 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.
Re: Show HN: Rust but Lisp
#25"Lust", or "Risp"?
Re: Show HN: Rust but Lisp
#26Unfortunately, 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.
Opus 4.6 handles elisp just fine. But I suppose YMMV.
Re: Show HN: Rust but Lisp
#27Unfortunately, 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.
Why are we even spending time on this. It's vibe coded slop. The creator probably never even ran it before it got to HN
Re: Show HN: Rust but Lisp
#28Unfortunately, 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.
That has definitely not been my experience as of late. I have produced multiple, largeish Clojure projects with AI that have been perfectly formatted and functional. Perhaps you were using an older or possibly smaller model? I am admittedly using Claude with higher end models and mid to high effort but it has been working great for months for me at this point.
Re: Show HN: Rust but Lisp
#29How 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.
Re: Show HN: Rust but Lisp
#30I 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!
[flagged]
Incorrect, and mean-spirited. Come on.