I enjoy using the Nim programming language at Reddit

It's great to hear Nim in production stories!

> I feel like Nim made me fall in love with programming again.

Same. It's just so frictionless and productive, and you know your code will run on basically any platform in a nice, efficient, self contained executable.

For me it's a language of sensible defaults. Speed and safety first, and opt-in machine level control. Want to target that obscure microcontroller? No worries: https://github.com/PMunch/ratel.

Want to use Unreal? Sure: https://github.com/jmgomez/NimForUE.

Want to target the web? Native React support with https://github.com/andreaferretti/react.nim or web apps with https://github.com/karaxnim/karax.

The list goes on! https://github.com/nim-lang/Nim/wiki/Curated-Packages

But, what if you want to use that battle tested C++ library? Nim can compile to C++ so you have native ABI FFI!

There's also a lot to be said for automation with AST macros. The language is built around them, they're not just a tacked on after thought. As a result, it's very easy to do everything from removing boilerplate copy pasta errors to creating mini languages or even generating APIs from data. This can give you new paradigms in approaching solutions for things that are quite painful in other languages.

I feel like this language could be a weapon of mass production for many businesses once they dip their toes in!

Nothing is without the cons. I would say:

* Libraries: there is no NPM ecosystem to get anything you need.

* Stack-overflow: If you looking for a aswers there might not be anyone who encounters it before. You might have to dig really deep to find some thing.

* Some times you might run into a compiler bug usually related with performance of the generated code. Like it generates correct code bug it's slow for no reason and minor changes to the code make it fast again.

* Relying on OpenSSL especially v3 especially on windows is a big problem, but thats more on openSSL i think. I actually wrote a library around this that uses platforms HTTP/SSL instead: https://github.com/treeform/puppy

* Not having HTTP gzip support in standard library. You can always work around with zippy though: https://github.com/guzba/zippy

* async stack traces are really hard to read.

* not enough docs around the different ways to do threading. There is no one solution some times you want a quick thing, some times you are doing CPU tasks other times you are doing network tasks (where async is better). But many big languages struggle here, there is no one fits all threading solution.

It's definitely not style case insensitivity which everyone loves to bike-shed about.

Great read, totally agree on the last point. Hope Nim gains more traction.

What really seems to characterize Nim is its ability to be used as glue language between different codes. C/C++/objective-c/javascript interoperability is native, python interoperability seems to be pretty good. It makes me think a lot to python before it exploded in popularity with machine learning and education

The super fast libraries mention in the article Pixie, Zippy, SuperSnappy all use GC. They can beat or tie with the best C libs. But in order to be fast they don't use GC in the critical hot paths but pre-allocate work buffers to the right size or allocate stack objects instead. Surprisingly, going outside the bounds of the GC does not feel that foreign or wried in Nim. It's not hard.