> It is similar to how many still don't belief in GC enabled systems languages. Well... don't give my application as an example. I have worked around the GC p

> It is similar to how many still don't belief in GC enabled systems languages. Well... don't give my application as an example. I have worked around the GC problem by using CL as kind of compiler for the application -- I built high level DSL that was then compiled to binary supplemented with small blocks written in ANSI C. If you think about it, SBCL already does this and so does JIT in JVM. I will give you an example: Before the order goes to the exchange, it needs to be validated against a set of rules. Like "do we have enough money to run this order?" or "How much of allotted limit this algorithm still has?" or "Is volatility on this market within bounds for this algorithm to be used?" The rules were written in Common Lisp DSL, then Common Lisp code converted it to a decision tree, then optimized decision tree, then compiled optimized version of the decision tree to a binary function. That function itself had no longer anything to do with Common Lisp, it could have just as well been written in ANSI C. Then Common Lisp code wired these functions to form the application. While most of the application code was actually Common Lisp (and some 20% of ANSI C), if you were market order and observed what instructions are handling you, none of them would actually be Common Lisp. After the initial setup, the Common Lisp application was running on only one core, and the constructed binary took over all over cores and was running without garbage collection on memory regions allocated outside of Common Lisp system. I hope this description makes sense... I have never before or after met an application that was built this way. As far as I know it is only one of its kind.