mratsim on HN version describes why they use and support the language:
“I’m from Status, Nim’s main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim.
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)”
what are the “not so good” part of using Nim today ?
This is an interesting question, and I hope more Nim users will give their opinion.
Here is a short personal list, from the top of my head:
stuff in the experimental manual is… well… experimental, and as such it is not polished, and you might hit some rough edges (pro tip: just don’t use concept and you’ll probably be fine)
the documentation has been greatly improved from what was there a year ago, but it could always be better
the situation with learning resources has also improved, but for example I haven’t seen many video tutorials
relatively small amount 3rd party packages (around 1000 packages currently available)
nimsuggest (tool for code completion, used by various editors) can consume large amounts of memory, which is annoying
no big-corporate backing, which limits the amount of people working on the development
after you use Nim for some time, you might like it so much that you don’t want to go back to your previous language(s) :)
also had problems with nimsuggest hanging/“thinking” for much too long, such thst I basically find it unusable in my vim setup
it has exceptions, which in my opinion is a plus when prototyping, but a minus if I wanted to write stable final apps (coming from Go)
the compile-time Nim interpreter (a.k.a. VM) has more bugs than the regular compiler, thus some advanced macros I want to write are not yet possible (though I can still write many macros well enough)
the standard library feels less consistent and polished to me than that of Go (but then, I have yet to see a language with a standard library of quality matching that of Go)
spec is more complex that in Go, and with more special cases (though written in a very approachable style)
Still, I find the advantages heavily outweigh the issues already, and hopefully situation will only improve. Personally, I find Nim to be an absolutely unparalleled choice for prototyping.
I’m using NeoVim with this plugin and the experience has been great. I find it working better than the usually recommended combo, VSCode + Nim extension.
Hmmm; now that I think of it, it may well be because I am by default using {.experimental: "codeReordering".} in all my projects; maybe this pushes nimsuggest out of balance?
I have to admit, clicking around and skim reading, Nim looks like the first language in a long time that has actually piqued my interest enough to try to learn it and write something with it. Nothing has done that since I found Ruby in the early 2000s.
Congrats to the developers! I remember first playing with it when it was still called Nimrod, in 2013. From going through the tutorials it definitely now looks like a modern Pascal in Python’s clothing. :-p
In a mostly good way though, so I should give it a good rummage and see how it works out. I think we need more languages targeting that Go-like level of abstraction. Anyone have suggestions for small projects to do with it?
If you were to try writing an editor (I have in mind especially a Markdown WYSIWYG editor à la Marktext, with WordStar keyboard shortcuts), or an email client, please let me know, as I’d be super interested in stealing… uh, I mean, *forking* some code from you in the future…
I’ve built a custom file uploading CLI tool for a customer with Nim 0.x in 2016. Why Nim? The backend was written in Python, as well as a prototype for the uploading logic (prioritization, chunking, hashing, access control) and getting from there to a single executable meant Nim was an obvious choice. Well, as “obvious” as 0.x niche languages can get :-)
Recently I was tasked to port the tool to Windows and jumped at porting the code over to 1.0 (or rather 0.22). I’ve had to do a couple of small updates to the code to fix some deprecation warnings and some smallish changes to the nim language, but could also remove a lot of code (Nim now has sha1 hashing in its stdlib, so I could remove my hand-crafted sha1.nim code). After that, the only change I had to make in order to make it run on Windows was changing the way how I read file. For some reason, Windows didn’t like my way of opening large files, but that was trivially fixed with a three-liner.
I know have a .exe, and the hardest part was getting a dev environment setup on Windows, and coping with Window’s idiosyncrasies, its badbadbad cmd.exe and DLLs: turns out Windows loads DLLs from its path m(
[Somewhat related, I’ve also ported a GUI app written in Rust to Windows in the last days. Overall a similar experience regarding “code once, run anywhere”.]
Congratulations! It’s always inspiring to see a group ship something neat!
I’m very curious about the Nim’s team thought process of finally releasing a 1.0 of a product. I can’t imagine this being an easy or quick decision. At what point did they know they wanted to ship this particular version as 1.0?
See also Araq’s personal blogpost about v1.
mratsim on HN version describes why they use and support the language:
“I’m from Status, Nim’s main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim.
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)”
Related forum post: https://forum.nim-lang.org/t/5213
Now that Nim has gone 1.0, I’m very interested in trying it out, to see if some of my current projects fit Nim better than they do Go.
Congrats to the contributors, looks like a lot of efforts have been put into it :)
Genuine question: what are the “not so good” part of using Nim today ? I would really appreciate your feedbacks :)
This is an interesting question, and I hope more Nim users will give their opinion.
Here is a short personal list, from the top of my head:
conceptand you’ll probably be fine)nimsuggest(tool for code completion, used by various editors) can consume large amounts of memory, which is annoyingTo add to this:
Still, I find the advantages heavily outweigh the issues already, and hopefully situation will only improve. Personally, I find Nim to be an absolutely unparalleled choice for prototyping.
I’m using NeoVim with this plugin and the experience has been great. I find it working better than the usually recommended combo, VSCode + Nim extension.
Hmmm; now that I think of it, it may well be because I am by default using
{.experimental: "codeReordering".}in all my projects; maybe this pushes nimsuggest out of balance?I have to admit, clicking around and skim reading, Nim looks like the first language in a long time that has actually piqued my interest enough to try to learn it and write something with it. Nothing has done that since I found Ruby in the early 2000s.
I can highly recommend that hunch and make an effort to learn the language deep. That’s what lead me to Rust from Ruby.
take a look at crystal, it’s in a similar niche but is ruby inspired.
Yeah, I wasn’t really sold on Crystal. Not enough delta, I guess?
Congrats to the developers! I remember first playing with it when it was still called Nimrod, in 2013. From going through the tutorials it definitely now looks like a modern Pascal in Python’s clothing. :-p
In a mostly good way though, so I should give it a good rummage and see how it works out. I think we need more languages targeting that Go-like level of abstraction. Anyone have suggestions for small projects to do with it?
I was going to Port my jumplist file manager from Go to Nim, and then go from there, and see what else might make sense to try to build in Nim.
Lobsters client that lets us ditch web browser with memory safety and easy extinsibility. ;)
If you were to try writing an editor (I have in mind especially a Markdown WYSIWYG editor à la Marktext, with WordStar keyboard shortcuts), or an email client, please let me know, as I’d be super interested in
stealing… uh, I mean, *forking* some code from you in the future…Nim is great.
I’ve built a custom file uploading CLI tool for a customer with Nim 0.x in 2016. Why Nim? The backend was written in Python, as well as a prototype for the uploading logic (prioritization, chunking, hashing, access control) and getting from there to a single executable meant Nim was an obvious choice. Well, as “obvious” as 0.x niche languages can get :-)
Recently I was tasked to port the tool to Windows and jumped at porting the code over to 1.0 (or rather 0.22). I’ve had to do a couple of small updates to the code to fix some deprecation warnings and some smallish changes to the nim language, but could also remove a lot of code (Nim now has sha1 hashing in its stdlib, so I could remove my hand-crafted sha1.nim code). After that, the only change I had to make in order to make it run on Windows was changing the way how I read file. For some reason, Windows didn’t like my way of opening large files, but that was trivially fixed with a three-liner.
I know have a .exe, and the hardest part was getting a dev environment setup on Windows, and coping with Window’s idiosyncrasies, its badbadbad cmd.exe and DLLs: turns out Windows loads DLLs from its path m(
[Somewhat related, I’ve also ported a GUI app written in Rust to Windows in the last days. Overall a similar experience regarding “code once, run anywhere”.]
Congratulations! It’s always inspiring to see a group ship something neat!
I’m very curious about the Nim’s team thought process of finally releasing a 1.0 of a product. I can’t imagine this being an easy or quick decision. At what point did they know they wanted to ship this particular version as 1.0?