This is actually a very well written critique. Usually we get things like "MOMMY! T-THAT GUY'S LANGUAGE IS NOT CASE SENSITIVE! M-MAKE HIM STOP!!!"
However, as Araq said, there are a few things which are incorrect. It's not actually your fault: in fact, it's actually a documentation problem. But let's go over them one by one. > That's why I think that any language that offers these [metaprogramming] > capabilities must make them gradual (i.e. generics vs templates vs macros) Well, that's exactly what Nim does. But more on this later. > have awesome reporting/debugging stories for it It does. Have a look at [treeRepr](https://nim-lang.org/docs/macros.html#treeRepr,NimNode), [lispRepr](https://nim-lang.org/docs/macros.html#lispRepr,NimNode), etc. and their relative `dumpTree`, `dumpAstGen`, etc. macros. These are totally equivalent to the same tools you get with other languages that support macros. Unless you're referring to some other very specific feature which I don't know of. > offer always runtime alternatives to the meta-programing so the language is > useable and productive without them What exactly do you have in mind here? I'll just note that [Nim's GitHub page](https://github.com/nim-lang/nim) states: > Nim is a compiled, garbage-collected systems programming language with a > design that focuses on **efficiency** , expressiveness, and elegance **(in > that order of priority)** Again, I don't know what you're referring to with a "run-time" substitute for macros, but it sounds like it would be very slow. Metaprogramming is necessarily a very resource-intensive task. That's why macros are usually a compile-time only construct, and the few languages which lets you modify the AST at runtime don't even try to be efficient (eg. the Lisp family). > Once you start with the language, the first 5 minutes feel great, if you're > familiar to the significant whitespace syntax it makes you feel at home and > with a promise of great performance! But then the illusion breaks, [... > cutting for saving space ...] you might not even know that you can override > operators in Nim at that point! This paragraph leads me to think that you're coming to Nim from Python. Now, while Nim's syntax certainly is very similar to Python ([so similar that something like this is very possible and it works wonderfully](https://github.com/yglukhov/nimpy)), trying to be a substitute for Python isn't Nim's main goal. Neither its second, third or fourth goal. **That is, you shouldn 't approach Nim as a "compiled, statically typed Python", but rather more as a "C/C++ replacement with modern syntax, package system, metaprogramming and much more"**. Essentially, **Nim is not to Python what Crystal is to Ruby**. > Unfortunately while some higher level constructs like generics are well > defined and understood at large by many users, full blown AST macros is a > different story. It's a very powerful tool with lots of sharp edges and > probably only seldom needed. In Nim however you're almost encouraged to use > them and I think that's a mistake, there is already a great higher level > general purpose meta-programming tool in the form of template (without term > rewriting), that should cover most use cases so any reference to real macros > in the docs should be prefaced with there will be dragons. **This is just not true.** [The manual itself states the following:](https://nim-lang.org/docs/manual.html#macros-statement-macros) Style note: For code readability, it is the best idea to use the least powerful programming construct that still suffices. So the "check list" is: 1 Use an ordinary proc/iterator, if possible. 2 Else: Use a generic proc/iterator, if possible. 3 Else: Use a template, if possible. 4 Else: Use a macro. Run Also, neither Nim's homepage nor its GitHub page have any reference to macros whatsoever. I don't know what makes you thinks that Nim forces metaprogramming down your throat. In fact, it would be very helpful if you could point at which piece of information lead you to believe that so that we could change it. But in any case, Nim is not Lisp. The vast majority of Nim's projects are written in a procedural style, with minimal OOP / metaprogramming added on top, and only when needed. Yes, there are things like [Jester](https://github.com/dom96/jester) which heavily use macros to build their own specialized DSL, but they are a minority. And in any case, I find Jester way more readable than its Ruby equivalent, Sinatra, if only because in Jester the DSL is "announced" with the `routes` keyword. > Anyhow, the main issue with the language is that from the very beginning > you're confronted with a huge cognitive load that is not easy to handle. Look > for example at the Official Tutorial, the surface of the language is too big > and while I'm not in a position to argue about the need or not of all those > features, I think that some of that complexity should be initially hidden, > offering discoverability paths as the user progresses. While I agree with what you're saying, a few things should be noted: * Araq has explicitly stated that he wants to cut some obscure parts of the language. We had a discussion on the forum not too long ago precisely about that. This also applies to the stdlib (yeah, you're right, it's too huge right now) * That said, I don't find Nim to be as big of a language as you make it out to be. When I think of big languages, I think about things like C++, Rust, Common Lisp, modern Java, modern C#, Scala, etc. It certainly doesn't try to be minimalistic like Scheme or Go, but I don't find it excessively big. Regarding all your other points, they're mostly right. Yeah, there's lots of stuff in `system.nim`, it's an acknowledged issue, it needs pruning. Yeah, stdlib is too big, it will be pruned too. Yeah, documentation is definitely not final (remember, Nim has yet to hit 1.0). I disagree strongly about the GC stuff being useless though. Nim has by far one of the best GC implementation when compared with other mainstream languages. It's very useful to game programmers (and there are lots of us in the Nim ecosystem). I also disagree about the community being unpleasant on GitHub. Technical discussions should not take into account feelings. See Linus and its methodology: it works. You should be able to separate between criticism aimed at your work and personal offenses.
