1: Nim is strictly and statically typed, so you wouldn't normally run into this kind of error. That being said, you can
|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¹|
|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⁴|
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
compilation switch can be used to turn of all runtime safety checks for extra speed.