[guenthert]

> Any news on the front of non-GC LISPs?

Can't help you there other than suggesting not to rule out LISPs with GC. Rather than making the presence of a GC feature a deciding criteria, I'd try to determine what the maximum tolerable response time would be and whether GC would push beyond that (and whether it'll be possible to mitigate this, e.g. by CONSing less or forcing (small) GC at opportune times). I mean, we're not in the 80s anymore where BASIC programs stalled for seconds to clean up their string space or even early naughts with pre 1.3 Java. There's been a lot of progress on GC mechanism and while the one offered in the LISP system of your choice might not be of the same sophistication as those in a recent JVM, GC gets rarely in the way.

[aredox]

I do agree GC is not a deal breaker: it can be chosen (Nim has three different GC engines, java has several VMs), it can be tuned... But there is still a clear categorical difference between GCed Langs and non-GCed, even if the border has become somewhat porous. And Rust (well, its predecessors) and linear types have shown there is a way forward to manage memory directly without shooting oneself in the foot repeatedly.