Nim uses the ORC "GC" by default, which is Reference-Count with cycle detection.
I don't get why calling the GC explicitly is needed in your examples given RC will drop memory as soon as it goes out of scope (and there are no other aliases to it). Perhaps the "cycle detection" happens at indeterminate times? But can't you use the simple RC GC in such cases? That should also ensure you don't use more memory than C at all?!
Telling you that you're factually wrong (which you could easily check yourself in 1 minute) and that you should not jump to correct people on the Internet, propagating wrong information without considering they may actually be right, does not amount to being nasty.
For all embedded purposes, I'd strongly recommend sticking with `--mm:arc` and avoiding cyclical data structures (can't see much of a use for that anyways).
With ARC, you don't need to "run" any runtime GC. ARC is a fully static thing, the reference-counting happens at compile time (static analysis) and the compiler injects (the equivalent of) malloc() and free() calls in the compiled code based on that.
It's great for embedded IMO. You get the performance of manual memory management with the convenience of GC. The only thing to be wary of is that it "hides" a bit when allocation happens. On embedded, you often want to minimize dynamically allocated memory for performance and heap fragmentation reasons, though the latter should be less of an issue with 64 mb of RAM. In nim, you just have to remember that creatin a string, a seq or a `ref object` allocates. So you want to eg. avoid creating and destroying a string repetitively in a loop. Instead create a `var` (allocate a buffer) once, outside the loop, and modify it as needed in the iterations. Everything else in nim (including plain objects, which map to regular C structs) is stack allocated, so ARC doesn't get involved at all.
