I supposed that you are concerned about Blitz and sudden death when times run out.
Chess is nowhere near requiring real-time like audio work (a desync is immediately heard) or high-frequency trading and Nim is being used for those. Actually for audio you might want to watch the NimConf video where someone asked the exact same question: [https://www.youtube.com/watch?v=ruT7sbs5O-Q&list=PLxLdEZg8DRwTIEzUpfaIcBqhsj09mLWHx&index=7&t=0s](https://www.youtube.com/watch?v=ruT7sbs5O-Q&list=PLxLdEZg8DRwTIEzUpfaIcBqhsj09mLWHx&index=7&t=0s) The gist is that they do use the GC, but only when starting a context for a single pool allocation and then that is reused multiple times across the context lifetime, and then collected at the context end. 1. Nim GC is triggered only when you manipulate a GC-ed type (ref, seq or strings by default or just ref with --gc:arc). 2. **Nim GC has a soft real-time mode** [https://nim-lang.org/docs/gc.html](https://nim-lang.org/docs/gc.html), you can set the max pause in microseconds. The memory allocation algorithm also an algorithm optimized for latency ([TLSF: a New Dynamic Memory Allocator for Real-Time Systems](http://www.gii.upv.es/tlsf/files/ecrts04_tlsf.pdf) 3. Real-time applications with a networking component invest in network card worth several hundreds of thousands and actually move location to be near the node/main server (finance), because IO severely dwarfs everything else. 4. Your GUI will need dynamic memory management, unless you reserve say 1GB of memory outright and always operate in this context.
