Nim had the following appeal for us:
- Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story).
- Nim allows us to use a single language for research and production: the Python syntax, and the fast compilation speed are very helpful. In particular researchers found the Nim codebase easy to debug as the overhead vs the Python spec was quite low (and the Python spec is using types with mypy)
- Nim has a easy C FFI and is one of the rare languages that can directly use C++ libraries, including header-only template heavy libraries.
- Nim allows tight control over memory allocation, stack vs heap objects, has support for Android and iOS and very low-memory devices as well.
- Nim also can be very high-level
- Nim is as fast as C and can resort to inline C, inline C++ or inline assembly when needed. (inline javascript or Objective C are possible as well)
- You can produce WASM code via clang, emscripten, binaryen, there is even a Nes emulator demo from 2015 running in Nim compiled to WASM here: https://hookrace.net/nimes/
- Nim has a strong type-system, including generics and type-level integers, boolean and enums.
- Nim has probably the best compile-time capabilities of all languages. I'm writing a deep-learning compiler in Nim macros. Someone wrote a Cuda code generator in Nim macros, and the code generation is extremely nice to write a VM, an emulator or any kind of assemblers as you don't need to use an intermediate step to generate your opcode tables or generate your functions from that table.
Now on a personal note, I use Nim to write a deep learning framework similar to PyTorch or Tensorflow.
I think it's the best language to solve the 2-language problem, i.e. write research in Python, R or Matlab and production in C, C++ or Fortran.
The operator overloading or even operator creation is very useful. The macros allow me to have a slicing syntax similar to Numpy, something impossible in C++. Compilation speed is very nice as a developer, I don't know how people deal with waiting for C++ CI.
I reimplemented a matrix multiplication with performance similar to handwritten assembly BLAS from OpenBLAS and MKL in pure Nim so I'm not worried about performance as well.
Now I'm onto refactoring the backend with a proper compiler (similar to Halide but since it will be macro-based, there won't be the 2-stage compilation issue)