issueczig (release-safe)rust (release)Nim (release)Nim (danger)
out-of-bounds heap read/writenoneruntimeruntimeruntimenone
null pointer dereferencenoneruntimeruntimeruntimenone
type confusionnoneruntime, partialruntimecompile time¹compile time¹
integer overflownoneruntimeruntimeruntimenone
use after freenonenonecompile timehandled by gc²handled by gc²
double freenonenonecompile timehandled by gc²handled by gc²
invalid stack read/writenonenonecompile timehandled by gc²handled by gc²
uninitialized memorynonenonecompile timememory always zeroed³memory always zeroed³
data racenonenonecompile timenone⁴none⁴

1: Nim is strictly and statically typed, so you wouldn't normally run into this kind of error. That being said, you can cast things to almost anything, but that is mostly for C interop. 2: Since memory is handled by the garbage collector you normally wouldn't run into any of these issues. Again though, you can allocate and free memory just as you do in C, which offers the same safety as C (ie. none). 3: All memory in Nim is zeroed by default, but whether the zero state is valid or not for your object type depends on how it's structured. But the standard library types like sequences and tables are valid empty structures without being initialised, and this is generally the style that Nim programs use. 4: This is coming with the new ARC/ORC garbage collection scheme and will then turn into compile time: (with the usual caveat that you can always avoid it and be unsafe if you want)

All in all Nim is fairly safe if you stick to the Nim layer, but since it has 1:1 C/C++ interop you can of course expose yourself to all the bugs that can arise from those languages (either by yourself, or through a wrapper). Nim is also designed to give very little overhead on runtime, which means that the -d:danger compilation switch can be used to turn of all runtime safety checks for extra speed.