Well, the link to the shootout statistics is probably not the best demonstration for Lisp speed/memory consumption/SLOC count relation. If you look into the Lisp sources there you will see that there are lot of things precompiled for the sake of reducing the execution time. Here's where the extensive memory usage and source size come from.

I intended to say that Lisp's and Go's both performance and succinctness in the wild are probably on par. But Lisp is already there for a long time.

This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense.

And I don't understand the comment about things being "precompiled". So what? Compilation is a natural step. Note that with most lisps "compilation" is not something you wait for while your server farm keeps crunching .c files, it's a natural step, sometimes happening behind the scenes.

> This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense.

Since I've posted a link to Shootout comparison of Go and Common Lisp I thought I made it clear which Lisp I was talking about.

> And I don't understand the comment about things being "precompiled". So what?

It means that a descent part of the computation was done in the compile (macroexpansion) time and this time was not measured and included into the total result. This may be great for cheating Shootout benchmarks but does not fairly demonstrate the performance of the language.