Fund Nim and help us develop it further!

General FAQ

What is Nim?

Nim (formerly known as "Nimrod") is a statically typed, imperative programming language that tries to give the programmer ultimate power without compromises on runtime efficiency. This means it focuses on compile-time mechanisms in all their various forms. Beneath a nice infix/indentation based syntax with a powerful (AST based, hygienic) macro system lies a semantic model that supports a soft realtime GC on thread local heaps. Asynchronous message passing is used between threads, so no "stop the world" mechanism is necessary. An unsafe shared memory heap is also provided for the increased efficiency that results from that model.

Why yet another programming language?

Nim is one of the very few programmable statically typed languages, and one of the even fewer that produces native binaries that require no runtime or interpreter.

What have been the major influences in the language's design?

The language borrows heavily from (in order of impact): Modula 3, Delphi, Ada, C++, Python, Lisp, Oberon.

What is Nim's take on concurrency?

Nim primarily focusses on thread local (and garbage collected) heaps and message passing between threads. Each thread has its own GC, so no "stop the world" mechanism is necessary. An unsafe shared memory heap is also provided.

Future versions will additionally include a GC "per thread group" and Nim's type system will be enhanced to accurately model this shared memory heap.

How is Nim licensed?

The Nim compiler and the library are MIT licensed. This means that you can use any license for your own programs developed with Nim.

How stable is Nim?

The compiler is in development and some important features are still missing. However, the compiler is quite stable already: It is able to compile itself and a substantial body of other code. Until version 1.0.0 is released, minor incompatibilities with older versions of the compiler will be introduced.

How fast is Nim?

Benchmarks show it to be comparable to C. Some language features (methods, closures, message passing) are not yet as optimized as they could and will be. The only overhead Nim has over C is the GC which has been tuned for years but still needs some work.

What about JVM/CLR backends?

JVM/CLR support is not in the nearest plans. However, since these VMs support FFI to C it should be possible to create native Nim bridges, that transparenlty generate all the glue code thanks to powerful metaprogramming capabilities of Nim.

What about editor support?

Why is it named proc?

Procedure used to be the common term as opposed to a function which is a mathematical entity that has no side effects. It is planned to have func as syntactic sugar for proc {.noSideEffect.} and func is already a keyword. Naming it def would not make sense because Nim also provides a iterator and method keywords, whereas def stands for define.

Compilation FAQ

Which option to use for the fastest executable?

For the standard configuration file, -d:release does the trick.

Which option to use for the smallest executable?

For the standard configuration file, -d:quick --opt:size does the trick.

How do I use a different C compiler than the default one?

Edit the config/nim.cfg file. Change the value of the cc variable to one of the following:

AbbreviationC/C++ Compiler
vccMicrosoft's Visual C++
gccGnu C
llvm_gccLLVM-GCC compiler
iccIntel C++ compiler
clangClang compiler
uccGeneric UNIX C compiler

Other C compilers are not officially supported, but might work too.

If your C compiler is not in the above list, try using the generic UNIX C compiler (ucc). If the C compiler needs different command line arguments try the --passc and --passl switches.