@Libman
Nim has a clear vision -- it's just that I fail to communicate it:
_Nim is a simplistic systems programming language with an AST based macro
system on top of that._
Its syntax is pleasant enough that it replaced all of my "scripting" needs too.
But that's not a lack of "vision", that's because the split between systems and
application and scripting programming languages is a historical accident, ymmv.
Note that the split between (pure) FP, imperative, OO and logic programming
makes much more sense and indeed Nim doesn't even try to be a functional or
logic programming language! Or much of an OO language for that matter.
And about the "zillion unfocussed ideas", that's quite biased. Facts are:
* Almost all of its features can be found in other languages too.
* New features arrive slowly (heck, isn't that what you just complained
about?) and more effort is spent on bugfixing and QA than on anything else.
* Features I would remove again have little significance: For example, I know
for a fact that the "tag tracking" is useless, it has not found a single bug in
any Nim project out there. Ok, let's remove it already. Well, not so fast, the
general effect system is also about exception tracking (useful) and `gcsafe`'ty
(essential for Nim's thread local GCs!).
* Many features are not Nim features, but stdlib features but it's hard for
newcomers to understand that and even if they do, they complain anyway:
* "How come slices do copy? These need to be a builtin language feature!"
* "What do you mean 'an interface is just a tuple of closures'?"
* "Why are the error messages so bad?" It's because `.async` is not a
compiler/language feature, it's a macro!
In order to turn it into a fruitful discussion: What feature should we
**remove** from Nim?
