Nimonic sounds just like mnemonic and if you close one eye and squint a little
it actually sort of applies.
Otherwise I'm fond of nimsy and nimish.
I didn't see nim-csfml when I was checking them out a few weeks ago, but I
found
[https://github.com/Vladar4/nimgame2](https://github.com/Vladar4/nimgame2) to
be by far the best documented and most extensive of the game frameworks that I
reviewed.
There are right ways and wrong ways of comparing languages. The right way is to
treat both of them respectfully and compare them as different approaches and
different styles, while still highlighting particular things that each excel at
or elaborating on why they made different design
The other `dump` is in the sugar module. Since I couldn't see all your code
before I wasn't sure if it was coming from there or something you wrote. Either
way the effect seems to be the same, glad you got it figured out!
I think you pasted the wrong code for charlie.nim. But anyway, it's a
limitation of the method call syntax. See
[https://nim-lang.github.io/Nim/manual.html#templates-limitations-of-the-method-call-syntax](https://nim-lang.github.io/Nim/manual.html#templates-limitations-of-the-method-call-syntax)
I think he left off the most important comparison: Nim is actually available
while V will be "open source mid 2019." I'm really curious about V and applaud
what the author is doing, and I am eagerly looking forward to trying Volt when
it's a little more stable. The comparison he wrote is is
Not OP, but in my brief few months using Nim it's
1\. Non-explicit imports
Sure, IDEs can go a long way toward helping with this problem, but if I'm
reading code on GitHub I often have no idea where a proc is coming from. This
makes it extremely difficult to trace how the code functions
