What do you think about the programming language NIM?


#21

Nim is a pretty nice looking language, but it’s not interactive. There have been some attempts to make a REPL but none every really worked. So while Julia is a language that’s difficult to static compile, Nim is a language that is hard to make interactive.

For me, that puts it out of the data science and scientific computing category since I utilize interactivity all of the time when exploring results.But Nim is still a good language for cases where static compilation is necessary.


#22

Could julia REPL to be extended as nim REPL (using LLVM/Clang as background)? I watched Keno’s Cxx.jl presentation and he said that C++ REPL is the most used feature of Cxx.jl.


#23

Nim is faster than Julia for some things. I was doing some naive Fibonacci benchmarks yesterday and Nim was about 50% faster. It was also faster than Rust. Only C with gcc -O3 beat it (and Cython, but that’s basically just 1:1 C). Nim is statically typed and transpiles to C, which is then complied with GCC. It’s not surprising that it’s faster than Julia in some cases.

It’s just not as flexible. I’m still astounded at the performance of Julia relative to its dynamism.


#24

However, it is interesting that species evolving on large land masses tend to be much more “competitive”.
Looking at islands is interesting. For example, consider the Italian wall lizards.

On the one hand, after being introduced to an island, they began evolving very quickly. Within a few decades, they “developed a completely new gut structure, larger heads, and a harder bite”. On the other hand, after arriving they also completely wiped out the native lizard populations – so being a small lizard population on an island did not exactly work well long term.

That is a broad pattern seen fairly consistently. Another striking example is the rather one-sided Great American Interchange (South America had been an island for millions of years, while North American wildlife was North American/Eurasian/African).

Obviously you lose the point of an abstraction/metaphor if you start dissecting it. If there is any lesson to take from that, it’s the fairly obvious “don’t live on an island”.
Small groups can move and adapt quickly, but stay in the fray: make sure you remain competitive with the giants, and learn all the lessons that you can. It seems lots of languages are gaining better meta programming support, for example.

@ninjaaron Julia doesn’t have tail-call optimizations turned on, so [benchmarks dominated by recursive function calls] aren’t going to be broadly applicable.
But yes, I wouldn’t bet that a language compiled with GCC is slower either.
It is fantastic that great tools like GCC and LLVM exist, to enable incredibly talented folks to implement a new language, and have it be blisteringly fast on many different platforms without having to develop their own back-end.


The State of the Julia Ecosystem
#25

I used Nim a lot in the past years. Its apparent simplicity hides many neat features, including metaprogramming and a robust type system. I even developed a TOML library, which has been recently included in the NimParsers organization once I announced that I was no longer interested in developing it (https://github.com/NimParsers/parsetoml).

Unfortunately, at the time I found that the compiler had too many bugs, particularly related to floating-point values, to be usable in the field of scientific computing. Moreover, most of the libraries I was using at the time had no proper Nim bindings. (It is very easy to create bindings for C libraries, but nevertheless somebody has to do that! Among the one I needed at the time, there were MPI, FFTW, …). Moreover, the fact that the language was not stable yet meant that every time a new version was released there was the possibility that my code would no longer compile. (Sometimes it happened that an apparently unrelated commit to the parser altered some feature I was using, without this being even mentioned in the changelog!)

This happened a few years ago. I understand that the development process is now more disciplined, and probably many of the bugs I found have been fixed in the meantime. Moreover, the release of Nim in Action (https://www.manning.com/books/nim-in-action) suggests that we are really close to the long-awaited 1.0 release. Once a stable version will be released, I might consider it for those projects where I would use C or C++ instead. This being said, I must however say that in my opinion Julia is far better for scientific applications: not only because of the REPL and IJulia, but also because the language has clearly been developed with scientific data analysis in mind!


#26

The Nim Gitter at https://gitter.im/nim-lang/Nim is a lot more active than the forum, for anyone interested in getting some answers in a chat format.