Comparison with other Rust LISP interpreters

[hoijui]

Hey! :-) As probably most others, I searched in a search engine for "rust lisp", and among others, found this project of yours. There are about 3 to 5 others, and - again: as probably everyone else - I am trying to figure out which one makes most sense for me. From a first glance I ... think your's is best for me, or even generally the most advanced, but I am a LISP newb, and ... I simply cant compare it well. Some of them are outdated, and I .. think yours is the only one with macro support, but .. yeah, I am unsure about everything. In short: I think it would be cool to have a comparison part in your README, even with the chance of it becoming obsolete (could be mediated with a date of the last update of that section or so). I'd not need a detailed feature matrix. just a list of links to the projects with one or two sentences would be fine. But also feel free to close this without doing anything!

[hoijui]

• https://github.com/murarth/ketos/blob/master/docs/README.md
• https://vishpat.github.io/lisp-rs/
• https://github.com/swgillespie/rust-lisp (old)

[brundonsmith]

Hi! I can't say I've really looked at what else is out there, but maybe if I have some time I'll do so and write some blurbs. Alternately, if you've already looked at the others and want to do a PR with comparisons, I'd be happy to review it

The bullet-points at the top of the readme hopefully cover the high-level priorities and tradeoffs, but I assume you've looked at those already. If you have any specific questions, or want to list out your requirements, I'd be happy to shed more light on things

I will disclaim, though: this is primarily a hobby project. It doesn't have any funding, I'm not using it in another project of my own, etc. I also don't consider myself an expert in either lisp or interpreter-writing; I have an amateur interest in both and this seemed like a fun thing to try and build (which it has been!). Past that point, I've continued to add features mostly when they seemed like fun, and I was bored, and felt like writing some Rust :) I've also gotten and reviewed/merged a few PRs, and I've fixed some bugs and added some features that people have requested, but it's all been motivated by my own interest.

With that said, I'm always really excited when other people show interest in using or contributing to the project, and seeing that tends to give me motivation to put more time into the project :)

[brundonsmith]

From a quick glance at the links above, mine looks most similar to lisp-rs, but I haven't dug in to see exactly how they compare (it is pretty cool that that one has been compiled to wasm, though!)

ketos seems like the most polished and most popular, though it takes a pretty opinionated stance re: being purely-functional with immutable data. My lisp aims to be more paradigm-agnostic, taking after Common Lisp moreso than Scheme or Clojure in some ways; I feel that in quick-scripting contexts, this kind of convenience is more important

I can't say from that quick glance (and without knowing your constraints) which one you should use, but hopefully that helps a bit

[brundonsmith]

I looked into the source code for lisp-rs and noticed that it doesn't appear to have a way to integrate native Rust functions, so that might be a sticking point depending on your use-case. ketos has SystemFns, but they appear to be hardcoded in the library, not something end-users can create themselves. So that may be a key differentiator for rust_lisp: you can write hot code in Rust to make it faster, or you can even use rust_lisp to script an existing Rust system, like a game engine or something (this was the primary intended use-case for it)

One other thing I do notice is that ketos appears to have a bytecode VM, instead of a tree-walking interpreter. This theoretically means your lisp code should run faster in ketos. However, that only applies to the lisp execution itself; since rust_lisp lets you drop down into Rust for intensive functionality, it may not matter as much that the actual lisp interpretation be fast. It all depends on the use-case

[hoijui]

Ohhhh thanks a lot Brendon! :-) lots of good info there!

My needs/interests ... to be honest, I could not even say. I am a total newb at LISP, have barely done more then maybe 3h of tutorials so far. I very much like the whole concept, and have colleagues who are proficient, and what not.. the universe tells me: Use LISP! but ... contrary to my colleagues, I am rather an engineer, while they are more.. coming from academia. And from engineers perspective, or say, from someone who wants to write software to be used by people and on CI systems and ... generally, in production ... what I have seen so far of LISP proper.. looks pretty bad (no standardized, simple way of producing reasonably small binaries, no culture of versioning libraries/dependencies, ....). I Learned Rust last year, and I really like it, and it is very well done from an engineers point of view, including all the tooling around it. So naturally I searched for "Rust LISP", in the hope of getting the niceties of rust, with the power and flexibility of LISP. In short: it is just a dream, very rough, abstract and probably unrealistic, .. either way, I can not say what I need, specifically in terms of features.

[brundonsmith]

Ah! I see

In that case I would say: if you're interested in really learning/immersing yourself in Lisp, you're probably better off diving into one of the major ones- Common Lisp, Clojure, Scheme, Racket, Julia. Those are a couple orders of magnitude more mature and featureful (and performant!) than this project, and will give you a much better idea of what Lisp is like as a category. Most or all of them will have integration with emacs and other tools, classic lisp features like hot-reloading, full documentation and community support, etc. They are full-featured languages you could build a whole piece of software with.

The primary goal of rust_lisp is to be a small scripting language that you can embed in Rust projects; the actual lisp syntax was mainly a matter of convenience, since lisp is very simple to parse and interpret compared with other languages. If a scripting language is not the main thing you need then I'm not sure I can recommend using it, especially if your goal is to get more acquainted with lisp in general

Clojure and Julia are the most modern of the "real lisps", and probably do more to address your complaints than the others. Scheme is supposed to be the most minimal and "pure". Common Lisp is old - it has a lot of legacy decisions that modern programmers might balk at - but it's also one of the most performant, battle-tested, and even practical, in some ways. It's multi-paradigm, has tons of libraries, has tons of built-in language features, and compiles to code that can be as fast as C.

Hopefully that's helpful!

[hoijui]

ohhh thanks a lot Brandon, again! :-) ok.. yeah I am sure you are right, this is probably not the best thing for me right now. Others also recommended Common ISP, because of the superb EMACS integration and all the features. Also, while it might not be perfect - the tooling for end users, deployment, packaging, version management and so on - I should be more playful and creative anyway; I am too serious these days. ;-)

[brundonsmith]

Closing this issue, but feel free to comment more if you have any other questions