Nim comes very close to be the perfect language for me (game development, machine learning etc.). Some things I experimented with including some links to show what I tried as follows:
- Fully controllable and plugable GC: I can decide for myself when the GC runs and for how long. Very important for games. If I do not like the GC I can even write my own or choose one of the many existing ones. See: http://forum.nim-lang.org/t/2646
- Meta-programming, templates, concepts etc.: To be able to write a machine learning library I needed something that can replace simple code (DSL) with more complex code using scalar math, SIMD, SPIR-V, OpenCL or Cuda. I also wanted to be able to automatically generate bindings for scripting. See: http://forum.nim-lang.org/t/2654 and http://forum.nim-lang.org/t/2635 . As I understood by reading the forums they will soon merge in many concept improvements. See: http://forum.nim-lang.org/t/2396
- Nim itself can be used as an embedded scripting language: Nim as a scripting language is used by the compiler to run Nim while compiling to generate new code. Nim as a scripting language can also be used as a more advanced configuration language (like Lua in the beginning). It can be used as an embedded or standalone scripting language as well. See: http://forum.nim-lang.org/t/2647 and https://github.com/komerdoor/nim-embedded-nimscript
- Compiling to C89 code (useful for creating libraries and cross-platform support etc.): I want my games to compile on platforms not supported by GCC or Clang/LLVM (actually I am sure they can support them all after some patching) but with their own C89 compiler. After compiling to C it is easier for me to see what the code will actually do. Still if I really want to I can choose to compile to Javascript, C++, Objective-C and LLVM (not officially included yet) as well. See: https://github.com/arnetheduck/nlvm
- Pretty good functional programming support (as far as compiled code allows for): For this I created a library that use the zero-overhead iterators. There are many alternatives as well and I like to be able to choose between multiple implementations of higher level functionality. See: https://gist.github.com/komerdoor/70d9c25820952624cf797890a1.... . Of course a better implementation is possible by combining this with concepts, generic dynamic method binding and all other of Nim's features. See the following again: http://forum.nim-lang.org/t/2654
- Easy integration of existing C code: I wrote part of my code in C (low-level) and another part in Nim (mid-level).
Some things which may get new Nim users in shock but I learned to love:
- Use of indentation using spaces for grouping like Python: I never really liked this but I cannot ignore that this made my code easier to read and discourages my preference for one-liners (yes I know bad habit and does not work well inside editors and with source-control).
- Multiple ways to write the same identifier (case/underscore insensitive): Liked this from the beginning. I am really consistent to choose a single style but all my C code is written using underscore (ex.: typens_do_something(x)) while in Nim in prefer to use camel case (ex.: typensDoSomething(x)) or fully drop the namespace entirely (ex.: doSomething(x) or x.doSomething()).
- Multiple ways to call methods: Both "abc".toUpper() and toUpper("abc") are the same. There are no namespace conflicts because Nim uses the best match for toUpper like: func toUpper(c: char): char or toUpper(s: string): string. It also makes it easier to add new methods for existing types while still being able to call the methods like if OOP is being used.
- Minimal support for OOP but encouraging composition over inheritance