> don't know what you're referring to with a "run-time" substitute for macros, > but it sounds like it would be very slow.
Yeah, sorry, it's clear I didn't explain properly that. I think I've clarified it on the response to Araq. > This paragraph leads me to think that you're coming to Nim from Python. I'm indeed familiar with Python but I wasn't expecting Nim to be a typed version of it. Now that you mention it, the language marketing is working well in that regard, because it's true that due to the syntax similarity it's easy to make that association. > This is just not true. The manual itself states the following: ... Great! I think that should be much more exposed on the documentation. I think that it's almost part of the design philosophy of Nim to be honest, so it should be much clearer to any newcomer in my opinion. > 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. That's a fair point, it might be a _confirmation bias_ since I do like metaprogramming and I might have been unconsciously looking for hints of it everywhere. The [features page](https://nim-lang.org/features.html) mentions _metaprogramming_ explicitely though, even with a `macro` example. The [wikipedia page](https://en.wikipedia.org/wiki/Nim_\(programming_language\)) screams metaprogramming too. It's a hard problem to solve though, on one hand the functionality is there, it's very useful and sets Nim apart from other languages which is great. But using metaprogramming is just **too ergonomic** in the language in my opinion, there should be some artificially placed resistance for it in a way that it's a tiny bit harder to implement one but remains frictionless when using them. > 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. Let me put it another way, the problem I see is not that the language is big but that its size is _flattened_ and you have to confront it early on. I think C# for example does a great job here, so realize it's size when you deep into it, unlike Scala that is on the opposite extreme. Taking those examples, I don't think Nim should try to be Go but it should try to be perceived at the level of complexity of C#. Specially because its syntax is so approachable that I'm sure lots of users are tempted to try it, it's the on boarding experience what needs work in my opinion. > 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 didn't say that. Just argued that from a marketing point of view it doesn't make much sense to advertise the different implementations, instead it should focus on the different types of software that Nim helps you create. If that's mapped to different GC implementations or a single one that can be tuned belongs to a section in the manual not on the marketing site. The other point was that I'm not sure if supporting all this options in the main project might be too much work when the focus seems to be to reach a 1.0 stable release, but that's just me guessing, I don't know anything about the maturity of those implementations or the bandwidth of the development team. I shouldn't had included that highly subjective opinion sorry. > 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. Agree that _technical discussions_ should not take into account feelings, it should be based on the merits of the implementation and take into account lots of factors (mainteinability, complexity, documentation, etc.). The problem is that when interacting on GitHub I don't know you and you don't know me, so a bit of courtesy can go a long way. I'm sure even Linus will say "hi" and "thanks" when going to the grocery store, so I don't understand why the interaction on a pull request should be any different. The review process needs to be totally technical but there is also a tiny part of human interaction going on, thanking someone for his time when closing a PR or an issue is a little gesture that makes the project more approachable in my opinion.
