
Ask HN: Does anyone use Nim language in production? - sharmi
How has your experience been compared to your previous tech?<p>How mature is the standard library? How abundant are third party libraries?
======
dom96
Judging by the upvotes there is a lot of interest in hearing answers to this
question and yet there are few comments so far. I will share my thoughts but
keep in mind that I am (extremely) biased as I am one of the core Nim devs.

> How has your experience been compared to your previous tech?

Previous to using Nim I was primarily using Python. This was a few years ago
now, but recently I was working on a project in Python and found myself
yearning for Nim. There were multiple reasons for this, but what stuck with me
was how much I missed static typing. The Python project used type hints which
I found rather awkward to use (of course the fact that we didn't enforce their
use didn't help, but it felt like such a half-baked solution). Dependencies
very often required multiple guesses and searches through stack overflow to
get working. And the resulting program was slow.

As far as I'm concerned, Nim is Python done right. It produces fast
dependency-free binaries and has a strong type system with support for
generics.

Of course, that isn't to say that Nim is a perfect language (but then what
is). For example, JetBrains has done a brilliant job with PyCharm. Nim could
use a good IDE like PyCharm and with its strong typing it has the potential to
work even better.

> How mature is the standard library?

To be honest the standard library does need some work. In the next release we
do plan on making some breaking changes, but we always lean on the side of
keeping compatibility even though Nim is still pre-1.0. Of course, sometimes
this is not possible.

> How abundant are third party libraries?

Not as abundant as I would like. Great news is that you can help change that
:)

The Nimble package manager is still relatively new, but you can get a pretty
good idea of the third party libraries available by looking at the package
list repo[1].

Hope that helps. Please feel free to AMA, I'd love to introduce you to our
community.

1 - [https://github.com/nim-
lang/packages/blob/master/packages.js...](https://github.com/nim-
lang/packages/blob/master/packages.json)

~~~
sharmi
I love the simple and clean syntax of Nim. The first time I was very impressed
with vim was when I used a wikipedia xml dump parser. What would have
literally taken days to complete in Python (atleast on my machine, and god
forbid if it had crashed somewhere in the middle) was done in a few mins by
nim (again on the same machine). I was blown away!

The one thing that concerns me a bit is that identifiers are partial case-
insensitive right?

(That means only the first letters are compared in a case sensitive manner.
Other letters are compared case insensitively and underscores are ignored.)

Does it hinder when you need to do refactoring?

Also, I work in vim, and grep for stuff when I need. I am not sure if
autosuggests and locating definitions/usage for variables would work. I am
sure I must be wrong as I believe the core developers would have thought about
it :) I just would like to know how

~~~
ddlsmurf
Identifiers are "style-insensitive", so case changes and single underscore
insertions don't actually change the identifier. There is exhaustive tooling
such as nimgrep and ide support built into the compiler (such as find symbol
at point equivalents) for helping when a convention is different. It is a
strong philosophical position, but it does allow style consistency across a
code base even when dealing with foreign symbols.

~~~
ma2rten
Wouldn't it have been better to just enforce one style over all nim code?

~~~
dom96
Perhaps, but I bet that would dissuade a very large proportion of people from
trying the language.

~~~
apotheon
The "style insensitivity" decision dissuades me much more strongly than some
case sensitivity style enforcement in the language would.

It seems odd to me that Nim developers chose to go with that "style
insensitivity" (which I would have predicted would be highly controversial and
very discouraging for many, many developers) but indentation sensitivity
(which is less controversial, but still _more_ controversial than indentation
insensitivity; shockingly large numbers of people dislike it, including me at
least when combined with some other language features).

If the goal was widest possible appeal and adoption, those two decisions
should have been swapped, I think. If the goal is related to some specific
philosophical stance, however, I suppose every language developer who doesn't
just want to recreate PHP or VisualBasic needs to pick the hill on which he or
she is willing to die, and only time will tell whether it will be worth it.

~~~
dom96
The goal of any language designer is not to appeal to the widest possible
group of people but to create a language that appeals to them. In this case
style insensitivity is something that Araq wanted in his language and so he
implemented it.

------
girvo
I did, and do at my new place of work too. Usually for tooling, automation,
etc. As of 0.17, I'm quite happy with the standard library, though I still
think the Futures impl needs a bit of work.

I'm now using it extensively for a confidential computing and block chain
project, which is quite exciting.

------
nimmer
> How has your experience been compared to your previous tech?

Having used Python, Go, C, Perl, Java, Nim is a breeze to code in.
Occasionally the compiler glitches and you have to delete nimcache. Very
rarely it fails to compile something and you have to rewrite few lines
differently. Not an issue. Build frequently to avoid any surprise.

> How mature is the standard library?

Not that much: it lacks examples and helper procedures that you would expect,
yet I still feel more productive with Nim than other languages.

> How abundant are third party libraries?

Look at the packages. Most of the basic stuff it's there. For small and medium
projects it's usually not an issue, occasionally I have to wrap functions from
a C library.

If you are looking for big, fancy libraries like Pandas and Sklearn, they are
just not there. Use Nim for tool and services instead.

~~~
ryanx435
> Very rarely it fails to compile something and you have to rewrite few lines
> differently

This is a huge issue. If you can't trust the compiler, it's not ready to be
used for any function that is system critical.

~~~
dom96
That depends on the frequency. Even gcc has bugs, albeit more rarely than Nim.
The great thing about Nim is that you can very easily get in touch with one of
the developers (me or Araq) on IRC/Gitter.

~~~
ryanx435
Yeah I don't care if you guys were on site providing 24/7 support, im not
going to use a language in production that can't be trusted to compile
accurately.

------
PudgePacket
Not myself personally, but I know this game was written with nim:
[https://impbox.itch.io/vektor2089](https://impbox.itch.io/vektor2089).

~~~
dom96
Yep, impbox is extremely talented having won the latest Ludum Dare recently
with Nim too[1] (A web version that uses Nim's JS backend also exists![2])

1 - [https://ldjam.com/events/ludum-
dare/38/smalltrek](https://ldjam.com/events/ludum-dare/38/smalltrek)

2 -
[http://static.impbox.net/smalltrek/nicojs.html](http://static.impbox.net/smalltrek/nicojs.html)

------
jboy
Yes, my startup Object AI uses Nim code in production. We have in-house
implementations of machine learning, computer vision & image processing code
in Nim, using a library called "Nim-Pymod" to integrate with Python's Numpy:
[https://github.com/jboy/nim-pymod](https://github.com/jboy/nim-pymod)

(As you can see, I was one of the authors of that library in a previous
startup. We haven't worked on Nim-Pymod in a while, alas -- I've been focused
on the new startup! -- but Nim-Pymod is sufficient for our needs right now.)

Our webserver main-loops are in Python; our number-crunching ML/CV/img-proc
code is Python extension modules written in Nim.

As a C++ & Python programmer, I'm a huge fan of Nim, which to me combines the
best of both languages (such as Python's clear, concise syntax & built-in
collection types, with C++'s powerful generics & zero-cost abstractions), with
some treats from other languages mixed in (such as Lisp-like macros and some
Ruby-like syntax). I find Nim much more readable than C or C++, especially for
Numpy integration. I also find Nim much more efficient to code in than C or
C++ (in terms of programmer time).

And Nim is a very extensible language, which enables Nim-Pymod to be more than
just a wrapper. For example:

1\. Nim-Pymod uses Nim macros (which are like optionally-typed Lisp macros
rather than text-munging C preprocessor macros) to auto-generate the C
boilerplate functions around our Nim code to create Python extension modules.

2\. Nim-Pymod provides statically-typed C++-like iterators to access the Numpy
arrays; these iterators include automatic inline checks to catch the usual
subtle array-access errors. Nim macros are themselves Nim code, which can be
controlled via globals, which in turn can be set by compiler directives; by
compiling the Nim code in "production" mode rather than "debug" mode after
testing, we can switch off the slowest of these checks to get back to direct-
access speed without needing to make any code changes. (And of course Nim's
static typing catches type errors at compilation time regardless of the
compilation mode.)

3\. Nim exceptions have an informative stack trace like Python exceptions do,
and Nim-Pymod converts Nim exceptions into Python exceptions at the interface,
preserving the stack trace, meaning you have a Python stack trace all the way
back to the exact location in your Nim code.

Earlier on in our development of Nim-Pymod, there were some occasional
headaches with Nim due to its in-development status. Occasionally the Nim
syntax would change slightly and that would break our code (boo). We've also
debugged a few problems in the Nim standard library. I suppose these problems
are an unfortunate consequence of Nim having a small set of core devs
contributing their time (rather than being supported by Microsoft, Sun, Google
or Mozilla). Fortunately, these problems seem to have stabilised by now.

The Nim standard library is reasonably large, somewhere between C++ STL (data
structures & algos) & Python stdlib (task-specific functionality). I recall
that the stdlib could use some standardisation for uniformity, but I haven't
been watching it closely for the last year or so.

Third party libraries are not abundant, aside from a handful of prolific Nim
community-members who have produced dozens of fantastic libraries (eg,
[https://github.com/def-](https://github.com/def-) ,
[https://github.com/dom96](https://github.com/dom96) ,
[https://github.com/fowlmouth](https://github.com/fowlmouth) ,
[https://github.com/yglukhov](https://github.com/yglukhov) ).

I'm happy to answer any other questions about using Nim in production!

~~~
nudpiedo
Being a hosted language (compiles to C/C++/Javascript) which are the biggest
pains?

Is there any way to ensure type checking for the exposed interfaces in
runtime? Let's say, exposing a function to the host language (C or Javascript)
which accepts a String and then passing an integer in the host language.

Did you ever use the javascript backend? How is the experience having a shared
code base among very different platforms?

How does interfacing to existing libraries look like? Any examples out there?

Does it really compile to C/C++ or just binary? If it compiles to code, then
is it possible to write libraries for mobile platforms as well?

~~~
jboy
I've never used the JS backend or C++ backend, so I can only talk about the C
backend.

With the C backend, the Nim code is transpiled to C code (surprisingly
readable C code, as far as auto-generated C goes), which is then compiled to
one of: a binary executable, a shared C library, or a static C library:
[https://nim-lang.org/docs/nimc.html#compiler-usage](https://nim-
lang.org/docs/nimc.html#compiler-usage)

In fact, Nim-Pymod _relies_ upon the Nim->C->library compilation, because it
uses the Python C API to produce Python extension modules:
[https://docs.python.org/2/extending/extending.html](https://docs.python.org/2/extending/extending.html)
, [https://docs.python.org/2/c-api/](https://docs.python.org/2/c-api/)

If you want to see a shared C library produced by Nim, have a play with some
of the examples provided with Nim-Pymod: [https://github.com/jboy/nim-
pymod/tree/master/examples](https://github.com/jboy/nim-
pymod/tree/master/examples) It auto-generates the appropriate Python C API
boilerplate functions around your Nim functions, then compiles the whole thing
as a shared C library, exposing the auto-generated functions in the shared
library.

Regarding runtime type-checking: Again, I can only talk about the C backend.
The type checking provided by shared or static C libraries will be whatever
the C compiler enforces... I haven't tested whether (or how much) this can be
violated.

Nim-Pymod _does_ auto-generate the Python->C type-checking code for you, so
you can't (for example) pass in a Python string when an int is expected by
your Nim function.

------
throwaway7645
I've just started writing a few scripts I'd normally use Python for (no
production) and have been impressed with the speed and binary sizes. Nim in
Action (book) is really good and what is missing to get the beginner started.
I'd like to see a PyCharm like IDE for Nim as well, but Vim seems to work
well.

~~~
dmlorenzetti
For those interested in "Nim in Action", its publisher, Manning has a 50% off
all e-books sale going through midnight today (27-May). Use code `wm052717lt`.

Usually when they have this sort of sale on a holiday weekend, they spin up
some new 50% off sale the following day, so check in again Sunday if you
missed it today.

~~~
dom96
Here is another discount code for today: wm052817lt

Also here is my referral link (helps me when you buy via this link :) )
[https://www.manning.com/books/nim-in-
action?a_aid=niminactio...](https://www.manning.com/books/nim-in-
action?a_aid=niminaction&a_bid=78a27e81)

~~~
throwaway7645
Can't remember if I thanked you on here before, but nice book. I'm eagerly
awaiting the print version to eventually show up at my house. Isn't it
supposed to ship this month?

------
u2227
One outsourcing company named Xored have choosen Nim as their primary language
few years ago, at least that is what a company owner have declared.

------
boduh
For those using Nim: how is the compile speed?

~~~
dom96
Very fast. I can bootstrap the compiler in under a minute. Compilation times
are further reduced while developing thanks to incremental compilation.

~~~
boduh
Sounds great! What about debugging? I understand that Nim compiles to C/C++ so
I am curious if I can use Xcode on a Mac and Visual Studio on Windows to debug
the generated C/C++ code.

------
galfarragem
Noob question: differences between Nim and Crystal?

~~~
samuell
From the crowd-sourced intr feature table I initiated [1] it turns out light-
weight threads is one of the the more prominent features that is only
supported by Crystal, and not Nim.

[1]
[https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...](https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w/edit#gid=0)

------
yglukhov
Here's a small teaser of yet not fully released game:
[https://www.youtube.com/watch?v=3Hzhqjiz-
Wo](https://www.youtube.com/watch?v=3Hzhqjiz-Wo)

> How has your experience been compared to your previous tech?

IMO. Comparing to C++, Objective-C, Java, Python, JavaScript, Python, D. Nim
is an amazing language from its design standpoint. First, why we have chosen
Nim for a pretty significant commercial project 2 years ago? Even though at
that time Nim was not as stable as it is now, the main bet was on its
hackability and compilation through C. That means a lot of things. E.g. we can
fix some bugs in Nim ourselves, because the entry level is much lower than,
say, with LLVM-based compiler. And if things go completely wrong and we can't
fix them, we could use Nim's {.emit.} pragma to actually inject C code. A
hammer of last resort :). As it turned out, there were some minor problems,
but all of them were fixed pretty quickly either by our team, or by friendly
Nim community. As for the language itself, it's simply amazing. These key
points about efficiency and expressiveness are 200% true. But you can easily
learn that from some simple pet projects.

> How mature is the standard library? How abundant are third party libraries?

The standard lib is OK, still could be polished a bit. We haven't had any
critical issues with it. As for the third-party libs. Of course you can't be
serious comparing Nim ecosystem to some more mainstream one, like js, python,
go, you name it. During our project we had to reinvent a lot. There's an
interesting observation though that things in Nim may be invented a lot faster
than in aforementioned techs, but yeah, someone has to do it =).

To summarize. If you're thinking whether it is worth to start a real
commercial project in Nim (the answer is of course YES! DEFINITELY! =),
consider the following:

1\. Of your products' 100% functionality how much can be done with third-party
libs? If the answer is "you take ruby on rails, write a couple of lines of
code, and done!" then unfortunately Nim is not your option yet. But if this is
a game, or a backend with a lot of logic, an app with simple UI and a lot of
business logic, there is a good chance that Nim is your option.

2\. If this is embedded code (like firmware or driver) you'd otherwise write
in C or C++, you should consider Nim in the first place.

3\. If so happened that Nim is a good option for you (which is rather likely),
make sure your team has one or two experienced developers which can handle
unexpected issues. Such developers should be fluent with C/C++ and JS (if
you're using Nim JS backend or asm.js compilers). They should know how stuff
works for the case, when you need a lib which is not available in Nim, and you
decide whether to bind an existing one from foreign ecosystem, or to write
your own.

4\. Don't be afraid of the fact that Nim is still pre-1.0. Minor things may
break occasionally, but nothing that single developer could not fix in a
couple of hours in a 100KLoc project. Such things happened pretty rarely in
our case and they are becoming even less frequent as Nim develops.

