The only thing I could ask for is categorization in the API docs. They're a bit hard to search or discover. Some of that is just the Nim automatic docs though. Other than that, fantastic library.
Been happily crunching away at Nim in production. I'm working on what is mainly a data analysis and report generation tool, compiled as a CLI executable that gets called by server scripts.
Nim makes fast, small executables. It has an excellent heterogenous JSON data structure and a good dataframe library. It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dictionaries) are pointers on the stack to heap data, where the lifetime is managed by the stack frame. I don't think I have any dynamic references anywhere in my program, and don't have to worry about GC at all. The type system is simple, sensible, and guides you to correctness with ease. Nim also defaults to referential transparency; everything is passed immutably by-value unless you opt out. Generics are powerful and work exactly as you expect, no surprises. Universal function call syntax is ridiculously powerful: You can write the equivalents to methods and interfaces on types just by making procedures and functions that take a first parameter of that type; not needing those abstractions greatly simplifies and flattens code structure. It's just procedures and objects (functions and structs) all the way down.
It's been a real joy to work with and reminds me of when I discovered D back in the day, only it's even better. If you imagine native-compiled type-annotated Python where nearly 100% of your code is business logic with no cruft, you're getting close to the Nim experience.
I use it at work for an important CLI tool that backs a number of our systems. My style is almost exactly like Python. Four-space tabs, snake_case, my own rules for indenting parameters and keywords. You do not need to use the official Nim style, you can absolutely write it like Python, Ada, however you like.
Nim. Fantastic choice for modern headless software. Simple obvious type system, preference for immutability and referential transparency. Dynamic collections are by default managed by hidden unique pointers on the stack. So the default RC isn't necessary unless explicitly invoked for a ref type.
Currently solo managing a 30k line data analysis application I built for my company. Easily fits in my head given the obvious pyramidal functional-like structure. Maybe two lines of memory semantics anywhere in the entire thing, and only one module that's OO with a constrained scope. Lots of static data files (style sheets, fonts) slurped up as const strings at compile time. Incredible performance. Invoked by our PHP server backend, so instead of doing parallel or async in the analysis, the server gets that through batch invocation.
Working stupid well for our product, plus I can easily compile binaries that run on ARM and RISC-V chips for our embedded team just by invoking the proper gcc backend.
Replaced an ailing and deliberately obfuscated 20 year old jumble of C and PHP designed to extort an IP settlement from my company. Did it in a year.
reply