I do not understand this position at all.  Regardless of the "tree
  shaking" issues, "too large language" is simply false.  The concept of a
  language being "too large" is vacuous.  Just because starting up a new
  process is thought to be slow, does not mean that the language is too
  large.  First, startup time has nothing to do with language size.
  Second, code size has nothing to do with startup time.  Third, neither
  has binary size or disk footprint or any of the other numerous idiot
  measures of size.  As a matter of counter-evidential fact, most of the
  Schemes I used before I came to my senses are still way, way slower to
  start up than the Common Lisps I have used, especially with actual code
  being used, and Scheme is about the smallest language you can get.

  Execing a new image is usually quite expensive, but forking is not, at
  least under reasonable Unices, so it should be possible to fork a running
  image of a large binary with almost no overhead.  Reasonable Unices even
  do copy-on-write and will not waste memory needlessly, either.  This
  means that the startup time has become _completely_ irrelevant.

  Furhtermore, the one-thread-per-connection model is inefficient compared
  to a tightly integrated I/O loop because a context switch is so much more
  expensive than merely running the same code with several file descriptors.

  Making languages smaller to get faster startup time in a system that has
  decided on the fork and exec model appears to me no smarter or effective
  than shaving to lose weight.

| And the Lisp Hacker that has not written their own Lisp-like language is
| not the true Lisp Hacker.

  Nor is he who has not seen the folly of the endeavor in time.