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.

Reply via email to