| > I'm also not a fan of canonicalizing variables so you can write them any way you want to, since it harms grepping and the consistency of code. Perhaps surprisingly, the opposite is true. You can enforce a style and a library that uses another style doesn't pollute yours and mix it all over the place. There's also `nimgrep` (never needed this in >5 years on this language), or `nimpretty` to normalise styles. > someday stop having to use C++ Nim can compile to C++ so you get ABI compatibility, and control over performance should be just as fine tuned. Nim should be able to run at the same speed as C/C++ since they both offer the same level of hardware access and portability. Depending on your needs it should be possible. > code tends to be both surprisingly terse while remaining readable, and fast to compile and run. This is one of Nim's most powerful features. Easy to read productivity. Prototypes end up being good enough, and it's got the teeth when you need them. The language default is 'fast and safe', all the fancy stuff is opt in when you need it. E.g., variables are put on the stack by default, heap GC is attached to the type rather than instance (static lifetime + RC/optional cycle collector). Variables are initialised to zero, but there's `{.noInit.}`, access raw pointers but with strong typing and construct/destroy hooks, and so on. Things like this: https://nim-lang.org/docs/manual.html#pragmas-linearscanend-... and the below computed goto pragma add even more control should you need it. Then there's the god-tier metaprogramming that lets you have optimisations that would be impossibly onerous to write, let alone maintain, manually, and give them the sweetest syntax you like. Full compile time VM in the native language, and type safe AST macros. Just standard Nim code, processing syntax trees with the standard library, say, outputting a framework from some data in a file, or providing a deep learning DSL that generates code for optimised matrix operations. It's like going from 1D to 2D. |
But as @arc776 it’s actually handy for making your code based more consistent. Python was always a bit of a pain where different libraries would be either snake or camel case causing your code to have a weird mix.