Generally speaking, and exceptions aside, astrophysicists are not programmers. They usually write bad code, but most of them are aware of this. They are sometimes able to abandon an old technology and adopt a new one, but reasons must be very compelling! (Examples: astrophysicists are slowly switching from IDL to Python, as shown by T. Robitaille during the last ADASS meeting [2].) Given the current state of things, I feel that Nim could raise a lot of curiosity in my field, but it would not be compelling enough to do the switch. Nim has a beautiful syntax, and I love its many features (macros!). But there are many things that are vital in my field and Nim lacks:
- No scientific stack. It's true it is extremely easy to create your own bindings to C libraries, but the number of libraries I routinely use are so many that the effort would be huge: FFTW, OpenMPI/MPICH, BLAS, LAPACK, GSL, and so on. Languages like Julia and Chapel have been designed for the scientific community from their grounds. Therefore, many of the routines provided by the libraries above are already available within the language itself or its standard library, in a coherent interface. Even writing all the Nim bindings to the libraries I mentioned above would provide a suboptimal experience. What would be lacking is a high-level layer which harmonizes the inconsistencies among the C libraries. A practical example: suppose you want to calculate the FFT of a nontrivial subset of the elements in an array, like array[10:320:4] (start from element 10, take 320 elements, but only one out of four). Using NumPy, is just a matter of calling fft(array[10:320:4]), but using C or Nim's bindings to FFTW requires an explicit for loop to create the temporary array to be passed to FFTW's functions.
- Both Julia and Chapel provide native constructs to ease the parallelization of the code. This is a must in cosmology, which relies on very heavy calculations ran on clusters with thousands of computing nodes. C, C++ and Fortran here have the advantage of making both MPI libraries and OpenMP constructs available at the same time (and don't talk about the many alternative libraries, like Intel's TBB [3]). Chapel is extremely strong in providing alternative (and easier) ways to express the parallelism of numerical computations. Furthermore, there are plenty of ways to further help the C++ compiler in parallelizing loops, using the "reserved" keyword and a bunch of #pragmas. The last time I checked, very little of this was available in Nim; see my post here: http://forum.nim-lang.org/t/1978/3. Apparently, nobody was able to answer my question, from which I concluded that the solution didn't exist.
- I feel Nim's installation and environment to be a bit "fragile". In the past, I had a couple of occasions to show Nim to my colleagues. Both times I failed to run the installation process from the beginning to the end without problems, as there were little inconsistencies between what the documentation says and what install scripts really do. Just a few days ago I reported a new set of problems I experienced with the two latest releases, 0.15.2 and 0.16.0: http://forum.nim-lang.org/t/2693; luckily, this time nobody was watching me :-);
- (This is probably linked to the previous point.) The lack of a clear path towards version 1.0 scares a lot of potential users, including my colleagues. I wrote a set of codes in Nim for a paper submitted to Astronomy & Computing, and that paper was almost rejected because of the reviewers' feeling that Nim was not «serious» enough. (I was able to publish it only after I rewrote everything in Python!) I hope that when you'll finish your book [1], this will help people to think differently. I cannot avoid comparing Araq's promises for version 1.0 (see e.g., http://forum.nim-lang.org/t/650/2, a forum thread which dates back to 2014) with Rust' roadmap towards version 1.0 and beyond: the Rust community has done an impressive job in delivering versions 1.1, 1.2 and so on every six weeks, as promised. This is surely due to Rust's larger user base, but I think it also shows a different attitude. (From what I understand, Araq has decided not to speak of dates regarding version 1.0 anymore, which is good; however, it would be even better to provide a date and stick with it.)
- Finally, I feel that a number of missing nice touches are hurting its adoption. The lack of decent IDE support, with refactoring and reformatting, is crucial. As I said above, astrophysicists are not programmers: often you have to incorporate ugly code, but you first need to refactor and reformat it heavily. Tools like `clang-format`, IDEs like Qt Creator and plugins for the most used editors are lifesavers! Last time I used it, Emacs' nim-mode didn't provide a confortable user's experience. Meanwhile, I have switched to Visual Studio Code, but I have not tried the Nim package [4] yet (however, I see that it still lacks many crucial features, like reformatting and debugging support.)
[1] https://www.manning.com/books/nim-in-action
[2] http://www.adass2016.inaf.it/index.php/participant-list/15-i...
