My personal subjective view: * We generally do not need more languages, there are more than plenty enough. What we need is more than a handful of _good_ languages which also support event based/async and threads and which are verifiable (~ have a good static analyser available) * 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. What we need is a _stable and reliable "core" (Nim + basic *standard_ libs). * We should _not_ care _at all_ about tiobe and similar "the coolest/most used/most asked about/etc." rankings. I know, I know, it's heresy but sometimes, e.g. with languages, the opinion of the majority/the masses is utterly irrelevant. Secondary point: the factors driving the masses are rarely rigorous and rational but rather (perceived/assumed) "coolness", famous names, "killer apps". Note however that a really good and efficient language significantly increases the chances to produce a "killer app". * 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. * Any, no matter how great, feature's effective value isn't defined only by itself but also and necessarily by its docu ~ useability (ease, efficiency) _and_ its being a well integrated part "flowing" within the languages philosophy. * A language is a means to an end and the _complete universe_ incl. docu and tools are decisive, not just the language. Example: Nim _can_ be debugged via standard debuggers. That's a big, big plus. Unfortunately though Nim's debugger support had quite some room for improvement.
_Of course_ it's unfair to demand that a 3 or 5 developers based language should provide something similar to what we know from C, Pascal, ... But at the end of the day the users of a language (well, many of them) need to work and earn their income; if that is significantly harder or less efficient than with say C or Pascal a language will see less acceptance and growth. * One major problem related to growth I see with Nim is this: Nim looks like it simple and is (somewhat loosely) often described a "the power of C with the ease and comfort of Python". We should see and understand that that also translates to expectations. Example: both C and Python developers are used to decent tool support. Landing on an evidently wrong line in the debugger or having quite sub par editor selections and support will have graver consequences than with people whose expectation are not shaped by e.g. Python. * If asked to provide one (and one only) advice to @Araq and the Nim team it would be this: 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 than when offering lots of stuff of diverse quality and in between no and modest docu and trying to please every group (from ITSec to gamers plus the web crowd). Last I'll return to the beginning. There are way more than enough languages - and there are more than painfully enough bugs and vulnerabilites in software. What is _really_ needed - above all - is a language that allows (but not necessarily forces) one to create bug free software. Nim seems to be capable to become a really good and important language + universe (docs, tools) but I'm afraid Araq and the team try to please too many diverse groups and seem to think that e.g. (basically it boils down to that) one editor (or rather a bloated abomination) is good enough. Sorry, no, it is not. 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. That said, I'm very productive with Nim (minus VSC idiocies) and I truly like it a lot. But I find myself too often turning to Ada or C for certain critical tasks (e.g. crypto). And yes, I _do_ love the Ada Studio _a lot_. Growth? I do not care. At all. If the offer is attractive and playing with a new thing is satisfying, they _will_ come. They always do.