I read the Nim manual a while ago (<a href="http://nim-lang.org/manual.html" rel="nofollow">http://nim-lang.org/manual.html</a>), back when it was Nimrod.<p>As a Python user, I loved it. Every single problem I had with Python, Nim seemed to have solved elegantly. Performance, distribution, typing... Everything looked perfect, and none of the Python expressiveness seemed to have been sacrificed.<p>But it was transpiled to C, and the abstraction was leaky. Every once in a while the manual would mention that certain structures were not supported, and it was clear C was the culprit. I think the most glaring example were nested functions, or something similar.<p>I thought to myself "this will bite me in the ass sooner or later" and gave up. Maybe it's time to try again. If they plugged the abstraction holes, this will be a killer language, with applications everywhere.
Great post. I thought I'd comment just to say about the relative URL ../what-is-special-about-nim not working as intended from the homepage and the link to <a href="http://nim-lang/" rel="nofollow">http://nim-lang/</a> which should presumably be <a href="http://nim-lang.org" rel="nofollow">http://nim-lang.org</a><p>Seems a shame to make such a pedantic and insubstantial comment on such an interesting article about a language I'd not come across, but thought the author might like to know.
Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.
I just realized something:
Nim is like a faster Python or a better Go lang<p>It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.
I tried it and it is easy and fast. But the ecosystem is still not very large.
I think that it should support building libriaries directly accessible from python including passing numpy arrays directly to nim. That would make a lot of people to jump right in creating libraries and thus extending its own ecosystem.
I wonder if it can generate bindings for Python like Vala does[0]? That would make it even more interesting for Python developers.<p>[0] <a href="https://github.com/antono/vala-object" rel="nofollow">https://github.com/antono/vala-object</a>
I keep coming back to it, and I really like it but wouldn't it be great if it had interfaces? I really want to restrict the generic type but there seems to be no way other than using templates[1].<p>[1]: <a href="https://github.com/Araq/Nim/blob/master/lib/pure/collections/lists.nim#L109" rel="nofollow">https://github.com/Araq/Nim/blob/master/lib/pure/collections...</a>
I played around with Nim and it has huge potential. It is early days and I would like to thank the creators of the language. A decent IDE is the only issue for me. I tried all the IDE options and it was stark. The idetools didn't work for me and the unit tests failed on Ubuntu 14.04.<p>At the moment small projects and libraries should be fine but the lack of IDE would be an issue for bigger projects.
> That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in.<p>What exactly does that mean? Does the end-user of my binaries require a C compiler? Which operating systems are "we" interested in. I'm interested in Windows and specifically Windows CE.
Nim has some good ideas but I can't get over the syntax:<p><pre><code> - Significant whitespace, but tabs are forbidden
- No block comments, save for `discard """ ... """`
- Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)</code></pre>
> Nim libraries are statically compiled into our binary as well.<p>Does that mean one can not use GPL libraries in non-GPL programs? With other languages you can get around that by linking dinamically.
I'm assuming "staticExec" is not sandboxed in any way...<p>It's one thing to make your compile stuck it's head while doing #include "aux" in windows, but completely different to treat source code as "shell"-script.<p>(I see the point, and it's a great feature, but with too much power).