issue	c	zig (release-safe)	rust (release)	Nim (release)	Nim (danger)
out-of-bounds heap read/write	none	runtime	runtime	runtime	none
null pointer dereference	none	runtime	runtime	runtime	none
type confusion	none	runtime, partial	runtime	compile time¹	compile time¹
integer overflow	none	runtime	runtime	runtime	none
use after free	none	none	compile time	handled by gc²	handled by gc²
double free	none	none	compile time	handled by gc²	handled by gc²
invalid stack read/write	none	none	compile time	handled by gc²	handled by gc²
uninitialized memory	none	none	compile time	memory always zeroed³	memory always zeroed³
data race	none	none	compile time	none⁴	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: https://github.com/nim-lang/RFCs/issues/244 (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.