> We generally do not need ever new features and gadgets. The Nim teams high > tolerance for funny experiments and a zoo of traits and whatnot is actually > negative in my book.
On the other hand, someone's "funny experiment" may be someone else's highly desired feature. But I understand the concern. Maybe it would be a good compromise to not have too many experiments running in parallel? > We should not care at all about tiobe and similar "the coolest/most used/most > asked about/etc." rankings. Agreed. Especially the "most asked about" metric can have many reasons which don't only depend on widespread use. For example, I'd assume that languages/features that are hard to use and/or poorly documented would lead to more questions. > Growth (as in "more devs. using Nim") should not be considered a goal but > rather a consequence of offering a good language, a good lib, good docu, and > good tools. I also think that a better ecosystem drives adaption, not the other way around. To me it seems obvious and I only mention this because I read an opposite view in the forum recently. Of course, there are counter-examples, but I think for wider adaption it's ecosystem -> adaption. > Offer less but make sure that what you offer is consistent, complete (e.g. > good docu) and good quality. Having, for example, only 25 basic libraries > rather than 250 may look poor but if what one does offer is of good quality, > well documented, and consistent one will (for diverse reasons) be more > successful [...] I agree with the idea, but wouldn't go as far as suggesting only 25. I think that would be too few to get most people interested who currently get interested enough to try out Nim. One problem I see with "not so high quality" libraries is that it's difficult to judge how many problems there will be. For example, I start a project and while I'm working on it, I find x is missing and y isn't working as well as I had expected. If I'm "lucky", I can work around the limitations myself; in the more frustrating cases I have no idea how to fix the limitation or it would take more time than the project I'm working on. If I have fewer, but better quality libraries it's easier for me to get an idea how difficult the project will be. This applies mostly to third-party libraries, but [sometimes](https://github.com/nim-lang/Nim/issues/15167) also to the standard library. > I'm finding myself looking too much at Ada since a while - and I don't like > that. I'd strongly prefer to have a solid basis to trust in, bet on, and > focus on Nim only. For me it's similar with Nim vs. Python (the language I'm most familiar with). If the objective is to "get the job done" I'd do much of my Nim coding (which admittedly isn't that much ;-) ) in Python. And "getting the job done" here does _not_ mean that the Python code will be hard to maintain and full of bugs. ;-) Still, I use Nim for private projects because I like the _language_.
