[makuto]

I do wish the C compiler was as fast as e.g. SBCL's compiler in terms of compile time, because multiple rounds of dependent macro compilation eats up a lot of time.

I think Lisps tend to optimize for throughput, but games have very strict latency requirements. Garbage collection pauses could cause frame pacing issues (not that C solves that completely, but it is at least not a built in disadvantage of idiomatic use of the language)

[moonchild]

Newer concurrent java GCs (shenandoah, zgc) provide consistent ≤1ms pause times independent of heap size. That's a reasonable latency for most soft real-time tasks.

[patrec]

Writing a low latency garbage collector (with decent throughput) is a non-trivial engineering problem and requires both high calibre engineers with specialized skills and a lot of funding. I fear the time lisp community has had either are long gone.

How much did the development of Azul's C4 or Oracle's Shenandoah cost in terms of money, talent and time and how much has this work lowered the barrier for less well resourced languages? I don't get the impression that the answer to this question is: "enough that we will soon see low-latency, high-throughput garbage collectors becoming the norm".

[AlchemistCamp]

Some older VMs like Erlang's also do very well in avoiding GC pauses.

In Erlang's, the key is that garbage collection is per process. (Note that Erlang processes are analogous to Golang green threads, not OS prcessses.)

[dugmartin]

And in the BEAM the garbage collector is only invoked when the heap and stack meet which means for most short-lived processes it never runs:

https://erlang.org/doc/apps/erts/GarbageCollection.html#over...

(btw, I'm enjoying the Reactor podcast, keep it up)

[AlchemistCamp]

> (btw, I'm enjoying the Reactor podcast, keep it up)

Thank you! Since we don't get many comments on reactor.am, it's hard to tell if it's useful for others to share our masterminds.