Added a FAQ

Unofficial-FAQ.md

@@ -60,4 +60,26 @@ typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof
 
 Then you are likely trying to compile the C sources with a 64bit version of GCC. If you are trying to do this then you should note that there is a ``build64.bat`` file which you should execute instead of the ``build.bat`` file.
 
-If the error does not resemble the above then the problem is likely with the C sources. Ask for help on IRC or submit an issue on github!
+If the error does not resemble the above then the problem is likely with the C sources. Ask for help on IRC or submit an issue on github!
+
+## Is Nim unsafe?
+
+Usually this comes from Nim's ability to dereference null pointers and it's deal with compiling to C IR. Nim strives to generate C IR that won't cause undefined behavior as easy as how it can be caused by hand written C code. But when there is hand-written Nim code that contains errors like dereferencing a null pointer, there are ways to avoid this:
+
+- `not nil` Annotation:
+  - You can use this annotation on any nilable type in your code and the compiler statically checks at compile time that your code can't possibly have a null pointer for that var
+- Compiler flags:
+  - you can pass flags like `-fsanitze`, or `-fsanitize=null` for nil checks, which provide minimal overhead.
+  - In the near future, `-nilChecks:On|Off` will be available for explicit nil checking and instead of Segmentation Faults, when a null pointer is dereferenced, it will be a NilError Exception
+  - Also in the near future, `-d:safety` will be available to use along with `-d:release` for performance _and_ safety (see: [#2809](https://github.com/Araq/Nim/issues/2809))
+- `-d:release` config
+  - by default, `-d:release` turns safety checks off, but if you configure `config/nim.cfg`, you can allow the checks you want enabled when invoking `-d:release`
+- Thread Safety
+  - shared memory via lockable heaps is a feature Nim seems will implement soon.
+
+You should also keep in mind these 5 points:
+  1. It's not a problem in practice in the real world, where people have access to a very good debug mode that catches all sorts of things at compile-time and at run-time.
+  2. It's not a problem with the right C compiler configurations.
+  3. It's not hard to "fix" this issue anyway. Where "fixing" means "pretending Nim created Ansi C code in the first place" (which it doesn't).
+  4. It's furthermore entirely deterministic in debug mode. It's nothing like a data race which you can never effectively test against.
+  5. Nim already encourages you to give the type a name and then 'not nil' can be part of the type definition easily