To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more.
I would love to see Nim succeed. I think there are a few roadblocks.
The main developer being a bottleneck is one. His intense focus has led to a bunch of neat features, but it's also made the language a bit crazy and incoherent and, in some cases, unfinished -- as if the author lost interest halfway through. The syntax is beautiful in some places, weirdly warty in others (the {.pragma.} syntax is a particular eyesore). It's full of odd, quirky features that seem like the author had a sudden idea but never considered if it was a good one to give a permanent place in the language. At such a young age it already feels crufty.
Nim is also not strict enough for my taste. Supporting nil (as default behavior) in this day and age is not really acceptable.
+1 Nim is too messy for me. And the codegen bugs are very annoying, just like black magic.
Also I don't like the Python-style with no end-marker. I'll be glad if Araq does plan to provide another syntax for Nim. But I fear the style war in the community.
Things I like about Nim:
1. Unified function syntax call, which makes my code more OO-like.
2. Many customizable operators and easy to grasp operator precedence.
3. The pegs library is small but very nice. I began Nim programming with it, wrote handy grammar validators with it, and finally got parser trees in pure Nim for the ASTs. Really fun.
Not much, because I hope Nim could be simpler and get the most practical features done right. I am dizzy with its syntax and STL now.
I can't speak for the article writer of course, but the Python-like syntax / significant indentation would be a deal-breaker for me. I'd suffer through a lot to avoid that. And back when I used C a lot myself, I found that even more objectionable. I often care more about syntax than many other language features - with a good syntax you can sugar over a lot of other deficiencies, but a syntax you dislike will stare you in the face every moment you use the language.
I am in some ways the same, but the other way around. I like Python-like syntax more than C-like syntax. But not to the same extreme as you, I wouldn't mind using a language with a C-like syntax.
What are your reasons for disliking Python-like syntax?
I want strong visual cues for the end of blocks most importantly. And I want the freedom to adjust indentation in ways that to me improve readability without consideration of whether or not it matches language expectations.
But also because I've yet to work in any environment where broken indentation due to tools with different ideas about how to handle it has not been a regular occurrence - indentation is brittle.
I think Haskell gets whitespace-sensitive indentation right. It is a lot less strict than Python, and if you didn't know it was whitespace-based you wouldn't necessarily realize it. Thanks to the functional nature of the language, the "hanging block" problem you have in Python (where the lack of an explicit end construct has blocks indent but never "close") doesn't really exist.
I wouldn't know - I gave up on Haskell because of the cryptic syntax long before I got to the stage of hating on smaller syntactic details... I love a lot of concepts from functional programming, but I wish I could get them in a language with a syntax more like Ruby and very much less than Haskell.
If I ever invent a language for anything more than personal use, I swear I'll provide several syntaxes, and an automatic translator. To each his own? FINE!
(I'll also shoot whoever tells me having several syntaxes is a deal breaker.)
I am a Nim fan too, but I doubt that Nim would fulfill the requirements of the author of this article.
At the very beginning of his post, the author says, "[the language] has to be reliable. I can't afford to spend my time dealing with bugs I didn't cause myself." One of the main reasons why I abandoned Nim after having used it more or less regularly for a couple of years is that so many things are still changing, and that compiler bugs pop too often. With every new Nim release I have got unexpected problems in recompiling my codes. This is the main reason why, despite still being a Nim lover, I have stopped using it for my projects. AFAIK, there is still no idea when Nim 1.0 will be released; there have been some optimistic announcements of its being imminent, but so far none of them has lead to such a release.
Later in the blogpost, the author adds another requirement: I do not want to spend my time porting old games to new platforms, I want to make new games. I need a platform that I am confident will be around for a while. Honestly, I think nobody can be sure where Nim will be a couple of years from now. There is practically just one coder (Araq) which understand the compiler internals, and by his own admission he suffers from a severe NIH syndrome which disperses Nim's scarce manpower. As an example, a tool so potentially useful as nimsuggest has been in a non working alpha stage for years because of the lack of people able to work on it (don't know if this is still true, though). IMO, this makes the future of Nim uncertain.
Don't misunderstand me, I still love the language and wish it can reach a state similar to Rust or Julia (which have a much larger and professional community of developers and are supported financially by a number of players). But I think that promoting it in this thread is a bit out of context: Nim is good when you want to toy with a nice language which gets so many things right (macros!), not when your primary objective is to have some language that just works and can be trusted in the mid-to-long term.
I wanted to recommend Nim elsewhere in the thread, too. For a lot of serious game devs, a language with a forced GC is often a no-go, for good reasons or bad, so that immediately eliminates a lot of potential candidates to replace C or C++. The only objections I frequently see people have with Nim once they look deeper into it are on syntax (not so much on indentation as on the symbol identifier rule -- case and underscore/dash insensitive except for the first character), current usability (not being 1.0), and expected longevity. Basically the same objections to Rust. (I think Rust can convert a lot of C++ game programmers eventually, I'm not so sure it can convert a lot of C game programmers because of the additional mental complexities in the name of safety, a low priority on a game dev's list.)
Nim seems close enough to C that you should be able to use the #line directive to map lines of C to lines of Nim source, keep variable and type names the same, and just use gdb.
To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more.
1: http://nim-lang.org
2: https://github.com/nim-lang/nim
3: http://nim-lang.org/docs/gc.html#realtime-support