> 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.