> Can anyone comment on the good and the bad points of Nim in larger (> 10KLOC) > projects?
_My experience with nim (gamedev, CLOC 45.199, 589 files, ~5 years using it, amateur programmer), this is my personal POV:_ > Bad points **Bugs** : You will have to deal with bugs in the compiler. Some of them are quite bad and to make matters worse, nim might give you either the erroneous line or nothing at all, so I don't recommend making big code changes without frequent nimc calls just in case. Things get wild when generics, templates and macros are involved. And it used to be much worse in the past. **Evolution** : Nim is changing constantly, deprecating things and replacing old behaviours with new paradigms. Every now and then I have to remove/replace by hand a lot of code because of this. I use devel, and given the state of the compiler/library, it doesn't benefit you to stay in a specific version, not recommendable. But I'm under the impression that many pharaonic features ends up being forgotten: Incremental compilation, hot code reloading, concepts, realtime garbage collector ... they get hyped too much and years later deprecation or replacement follows. Sometimes this concerns me, I fear I will reach a point when it won't be feasible to upgrade the compiler If I don't want to refactor completly my code. I have to scan the irc logs every now and then to see where things are heading. I have to say that communication is quite bad, and it doesn't help that RFC's are hidden in a different repository. I suggest to create a thread here for every RFC that is made. **Limitations** : Cyclic imports and procs ordering. Apparently, given the complexity of the compilation, it is not possible for nim to know the definition of procs before hand, which means that, sometimes, you need to forward declare procs. This is the lesser evil, but I find it quite archaic. On the other hand, cyclic imports is more serious. Nim doesn't support it. With almost 50K lines of code, not for a library but a complex software like a game where there is not a small set of primitives but lots of systems that interact among them, I have to scratch my head several times to organize my code. Because the project grew in an organic way, as you may expect, you cannot make a flawless design. The justification I read for not supporting them is that "is code smell", but casting is code smell, mutating is code smell, globals are code smell, and here we are. Being code smell is not an excuse when the perfect design is not at reach ever. The hacks I write to workaround this (big modules with many types, lots of includes, global public var procs that are initialized at runtime, which renders any compiler optimization impossible) makes my code ugly to read but comprehensible for the compiler. Global import for some std modules is broken, makes the compiler crash, and debugging that with 50K lines of code is not possible. With the new 'unused import' warning, useless. I want to have some modules that work like system (contains procs/types that you can use everywhere without explicit import) but you get houndreds of warnings, so now I have to pollute every module with imports. I could disable the warning, but who knows if the warning will evolve into an error in the future. **Compilation speed** : Nim is getting slower, with roughly the same number of files it now takes two times what it used to need to compile last year. Why is that? I think the maintainers should watch out for this. Everybody praises nimc speed, but my computer is quite old, so I get to notice when the compiler gets slower. Please fix this! > Good points **Speed and syntax** : I can't leave nim because it has the clearest syntax while being as fast as c. Rust syntax is ugly, zig has semicolons and braces in 2020, crystal has 'end' and no windows support. As Radiohead says: "I stick with you because there are no others". It is just a great combo. **C bridge** : If you need a library and can't find it written in Nim, you can interface with C. It has some rough edges, but overall it does the trick, I don't miss Java ecosystem. **Activity** : both community and language improvements are active. Every week there is always something new. **Crosscompilation** : Nim supports a wide array of targets. I wrote more about the bad points that the good points, but the fact that I'm sticking with Nim says that the good outweights the bad points. Because most projects in nim are either libraries or small programs, I don't think some of the issues that arise from having a big and heterogeneous code base receive enough attention.
