All these "small lisps / lisp-in-go / lisp-to-xyz" are great and I do applaud the exercise and what is produced, and I also appreciate many of of these projects are for learning or fun projects.

BUT if by chance you or your project is one of the more "serious lisps or next-lisp-vibes" hear his:

Before you even think about speed or benchmarks(size,spec,speed,lang) remember we live in a connected world that is multi-core.

First prize for your home-brew lisp that would make me sit up and take notice is if it has very easy net-libraries built-in (http (client + server), websocket, sse, json etc) I think that is one of the things Go(yes I know not every like it, but the real world usage is real) got right, the std lib was very "modern" at least to the point of real-world usability. Multicore is a close second prize :)

Network-libs (stupid easy ones) and the concurrency concepts is the very first thing I look for in a lang or lisp-derivatives

My 2cents :)

Why do you need to build them in when you can just load your favorite libraries that do these functions with https://www.quicklisp.org/ , especially for http the great libraries by Fukamachi: https://github.com/fukamachi parallel processing: https://lparallel.org/ etc.

I'm very grateful that common lisp does not version up (like python), but you can always load a new or newer version of libraries with no impact on your core production code. (Such as a rewrite when the language gets a new version - this never happens with Common Lisp)

>Why do you need to build them

Many of the projects I referred to are not "QL Compatible"

[0] https://www.ale-lang.org/

[1] https://github.com/nukata/lisp-in-go

[2] https://github.com/pixie-lang/pixie

[3] https://github.com/candid82/joker (Clojure like)

[4] https://janet-lang.org/ (more Clojure like than lisp like, but still brilliant and very polished )