Nim is realtime garbage collected and compiles to optimized C and it can use the C ecosystem of libraries and tooling. It also produces smaller binaries than Rust and is faster for most tasks.
Realtime just means that actions triggered by event occur in an explicitly bounded time. It doesn't usually mean that they occur in the same time. So a GC with bounded pause could be used in a realtime system assuming you could guarantee the explicit bounds.
I can't comment on whether or not this is true of Nim and pause time probably isn't sufficient (depends on how it's defined) but they're not mutually exclusive.
And most kernels don't need to be realtime unless they are realtime kernels.
Having said that, of course, the vast majority of GC systems are most definitely not realtime, or anywhere close. But that's just actually true, not theoretically true.
You can't guarantee explicit bounds on when a given resource will be collected with GC. Bounded times can provide upper bounds on GC pass runtime, but they do that by potentially deferring further collection. Those deferrals make it nondeterministic.
> And most kernels don't need to be realtime unless they are realtime kernels.
That's not true. Most (all?) kernels have internal realtime needs, e.g. responding to interrupts.
There is a way to write a kernel with a GC'd language, as Niklaus Wirth has demonstrated, by circumventing the GC where needed. But the critique I was bringing up was simply that there's no such thing as a realtime GC.