kunabi's comments

At the request of John McCarthy, Lisp’s creator, no single language that is a member of the Lisp family is to be intended to be the definitive dialect; that is, none is to be called just “LISP.”

So much innovation has happened since the CLHS that to put up a fluff site feels like an effort of "resurrection". When in reality the Lisp family has continued to evolve since then. To limit yourself to just CL, as I did, for a long time, results a bit of a 'losing my religion'. You'll be confounded by things long since solved, and in the end perhaps write all of "Lisp" off. Do yourself a favor and keep and open mind to the family, and not one common incarnation that predates some developers.

Gerbil/Gambit do this already. Fully static binaries, and are a ton faster than Chicken.

Good to hear someone had good interactions in #sbcl Still have a bitter taste from attempting to report the issue there.

I've been working on a CL project for a couple of years. Was my first big stab at using CL for something other than a toy. Sbcl is a nice choice, but far from the only option. It has many tradeoffs. CL is not without its frustrations. Documentation that has not aged well. A community that can be less than welcoming. (in contrast to say the Racket community) Inconsistencies, e.g. first, nth, elt, getf, aref... However portability appears to be a strong point vs on the scheme scene. Single binary compilation on SBCL/LW/ACL/CCL are great. Found GC to sbcl to be lacking on large garbage rates. Tended to promote garbage to a tenure that prevented it from being removed. It would max out 32GB of memory, even with explicit gc's enabled between files. Where as the other implementations would stay below 4GB.

So ymmv.

Performance benchmarks using cl-bench really highlighted some strong points http://zeniv.linux.org.uk/~ober/clb AWS Cloudtrail parser. https://github.com/kunabi/kunabi