Great write-up! I expected this to reference a few "normal" language features like static typing, operator overloading, or generics, but instead it was a list of some really neat off-the-beaten-track features:<p><pre><code> * Run regular code at compile time
* Extend the language (AST templates and macros);
this can be used to add a form of list comprehensions to the language!
* Add your own optimizations to the compiler!
* Bind (easily) to your favorite C functions and libraries
* Control when and for how long the garbage collector runs
* Type safe sets and arrays of enums; this was cool:
"Internally the set works as an efficient bitvector."
* Unified Call Syntax, so mystr.len() is equivalent to len(mystr)
* Good performance -- not placing too much emphasis on this,
but it's faster than C++ in his benchmark
* Compile to JavaScript</code></pre>
A little OT: Courtesy of the Reddit discussion of the OP, a reference to the discussion on Wikipedia about Nim, or rather, the discussion to delete its Wikipedia entry:<p><a href="https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Nimrod_(programming_language)_(2nd_nomination)" rel="nofollow">https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...</a><p>At what point does a language become noteworthy enough for a site that contains full entries for side characters in non-canonical Star Wars novels?
Thanks for the great write-up.
In addition to straight-up language features, what draws me to play with Nim is the full environment that has already been built up including module packaging and debugger (particular pain points when moving from Python to Golang).<p>Additionally, having compiled executables solves a Python pain point. I love Python, but distributing packaged executables is an ongoing pain point.
I've had my eye on Nim(rod) for a long time. I think this language may be the right thing, at the right place at the right time.<p>I haven't seen a better boat for Python refugees to jump into. It's certainly worth evaluating if moving from a Python2 codebase, rather than porting to 3.
It's far enough along that it can start poaching users looking for the best place to jump off from 2.x.<p>The only thing I'd like to see them somehow do, is add a CPython2.x library compatibility layer. If that could somehow be engineered into Nim before 1.0.. I think I'd declare Python3 to be in serious trouble.<p>The users WILL come if that's done. Maybe take a look at Nuitka in how to make this possible with the binaries that Nim produces. Or even just include the CPython2 runtime in the compiled binary if a user includes Python(2) code.
Nim is great, and this article is great, except until now no article about nim managed to sell it to me like a simple Golang example including channel and go routine.<p>Could any Nim advocate demonstrate a simple program that:<p>less than 50 loc<p>shows the greatest strength (1 killing selling point is enough)
Nice article.<p>I was going through trying to follow the instructions and hit a couple of issues:<p>-For "You should then add ~/.nimble/bin to your $PATH" it took me quite a while to figure I had to enter "ln -s ~/.nimble/bin/nimble /usr/local/bin/" in my Mac's terminal to do that. I guess experienced devs know that stuff but beginner here.<p>-There's a bug in the client.nim and server.js code where the client refers to element "foo" but the server refers to element "item". Changing them both to foo got it to work.<p>Nim seems kinda cool.
FWIW, I did a more direct translation[1] of the Nim code into C++. The current C++ code does things like memcpy a std::bitset on every recursive call. I also wanted the code to be doing the exact same thing as Nim is (vector with 1 byte per bool, globals for data, and I left everything as int when I would normally use other types).<p>The result is that C++ now just barely outperforms Nim: 1074ms for C++ vs 1165ms for Nim.<p>[1] <a href="http://ideone.com/q838cJ" rel="nofollow">http://ideone.com/q838cJ</a>
>Yes, that's right: All we had to do was replace the var with a const. Beautiful, isn't it? We can write the exact same code and have it run at runtime and compile time. No template metaprogramming necessary.<p>Worth pointing out is that modern C++ does this too. Just add a constexpr, no metaprogramming necessary.
Modern C++ really does feel like a new language.
Special about Nim is also that Wikipedia consistently tried to delete the article about Nimrod (and did), because someone considered it not noteworthy.
What a joke those editors are. If you have no idea about software languages don't interfere.
I'm not sure I like Unified Call Syntax. I think myvar.len() should be different to len(myvar), even if they end up returning the same value. Then again, I'm probably missing some key reason why it's useful.<p>Adding my own optimizations to the compiler sound useful enough. I might see if I can implement this in the language I'm making.
I copy/pasted the code in the article and compiled each one. I am getting very different ratios compared to the ones you posted:<p>tmp$cc -Wall -O2 test.c -o test && time ./test<p>real 0m1.041s
user 0m0.998s
sys 0m0.029s<p>nim-0.10.2$./bin/nim --opt:speed c test.nim && time ./test<p>real 0m1.943s
user 0m1.894s
sys 0m0.036s
What I don't like about Nim is that there is not a repl. In Lisp and Clojure you don't need to compile things.<p>Could someone give a brief comparison between Clojure and Nim? Let's suppose that we implement Clojure in Nim is this a crazy idea?, What about implementing Shen in Nim?. Many people complain because sbcl is not easy to use with C++ libraries, could an implementation in Nim amilliorate those problems?. Many more questions arise but those mentioned are enough.