Minimal Lisp binaries

Nearly all lisp dialects have native code compilers, and many can produce standalone executables. One thing I don't understand however is why executables require the full run-time? especially when your code doesn't use eval. Is there a way to use create a minimal image with sbcl that only includes the functions your program uses?

>>21
The executable must still be loaded into memory and transferred to the CPU. The most wasteful the binary, the more cache it uses, the more time is wasted on memory access.

>>25
Come fucking on, you'd have to tie your dick in knots to make executable code have a noticeable footprint on a modern machine's memory or cache. Data take up much more that code. I've never seen the size of a binary be a real performance concern.

>>26
Guess you've never been an embedded developer, then.

>>27
And before you ask, yes, this makes sense in the context of lisp. See http://zh.soup.io/post/122393574/Hedgehog-an-embedded-Lisp-in-20k or http://umlautllama.com/project.php?ShortName=Lithp or such.

>>19
Who are you quoting?

>>12
Rust doesn't have C-like syntax.

>>13
All of that is a crude ad hoc implementation of a generational GC. When will you Seppletards realize that your manual memory management boils down to reinventing (shittiest, error-prone and underperformant forms of) GC?

>>31
That's actually much faster, since there is no copying. But it only work under strict rules for lifetime. This is an example of why lower level languages are sometimes better. You have more control over these things, and can pick an implementation for a feature that works better, possibly with more restrictive assumptions of use, but with assumptions that hold. Higher level languages need to pick solutions that work under weaker assumptions.

>>25-san, have you not heard of demand-paged executables? The kernel maps executable sections lazily through generic mmap().

But still there's no excuse for a 400-kilobyte hello-world. Man up and stick the stdlib in a shared object you hippies, or you'll be in a Cabal-esque world of packaging hurt when those unmade decisions mount up over the years to finally rend you a constellation of new ones.

>>30
On the contrary: it's solidly a curly-brace language. The declaration syntax, match clauses, etc. come from ML and the like, but those don't do curly braces [except for Haskell (which gets it wrong)].