3 ms·

I'm a PhD student in physics, working on CAST [1], a small experiment at CERN. That fortunately means I don't depend on other peoples' code too much. With the

I'm a PhD student in physics, working on CAST [1], a small experiment at CERN. That fortunately means I don't depend on other peoples' code too much. With the C++ interpreter of ROOT you can run so called ROOT macros. They are basically just C++ files containing your code at top level in pair of `{}`. The "funny" thing is half the time you run a piece of code it'll work the first time. But then running it again will cause the interpreter to segfault, due to the mess of global state and the half baked memory management of ROOT. And don't get me started on the usability of the ROOT classes. A huge amount of stuff is string based, so throw away your type checking guarantees. I mean why bother... Since I really didn't want to continue working with ROOT for my PhD (after having used it before), I decided to ditch the previous data analysis code and start from scratch [2]. I decided to use Nim for it, because it provides me with a powerful language (on par with python for my purposes - aside from admittedly certain libraries, which I had to wrap), yet still being as fast as the old ROOT code (in fact faster for my data analysis, but the comparison is problematic). Yeah, it cost me a lot of time to get "back to where I started", the code itself might also not be a shining example of perfection, but I learned a huge amount about programming and I understand every piece of it. It was totally worth it. The gains in efficiency thanks to Nim and due to the fact I know the codebase means I make up a lot of the lost time anyways. So to any people out there who may be in a similar position, don't be afraid to throw out what you don't like. :) [1] https://home.cern/science/experiments/cast https://home.cern/science/experiments/cast [2] https://github.com/Vindaar/TimepixAnalysis https://github.com/Vindaar/TimepixAnalysis

SiempreViernes 7y ago
Ah, axion searches! Who said you can't get paid for staring at a wall? How come you didn't go with Julia? (or Fortran for that matter?)
- V1ndaar 7y ago
  Haha, well you can get payed for it, but you won't be payed well. It's hard to give an easy answer for that. But let's step back a little: I played around with Julia several years ago. I don't know when exactly, probably in 2015 (?). Back then I thought of it as a faster python for science. Many things I would use python for back then I could have done in Julia too. Others I couldn't though, because the eco system was still too small. And while Julia was somewhat faster for the things I tried, it wasn't amazingly faster. My interest in the language dropped sometime after that. But still, I felt like it was a language targeted specifically to scientists. Many things I wanted from my analysis framework however were outside that bubble I felt. I didn't simply want to write a faster "analysis script". I do realize however, that the language has evolved a lot and I'm happy it's finding acceptance! Fortran on the other hand, I never really considered. I suppose modern Fortran is a pretty good language though. So why did I choose Nim then? It gave me: - the ability to produce standalone binaries I could just put on any data acquisition pc without a hassle (well ok, be careful about old glibcs) - it's fast, and I felt right at home syntax wise coming from python - the community is amazing. The first time I entered Nim's IRC channel I noticed Araq, the creator of the language, answering random people's questions! In general the community allows for a super quick feedback loop to learn the language - it's a pretty concise language. The whole manual can be read in less than a day - having written some Clojure, I loved the idea of a powerful macro system - after seeing mratsim's arraymancer library [1] I was happy to 1) have a numpy substitute and 2) thought if one person could write such a great library in O(1 year) it must be a pretty awesome language to work with :) - being able to trivially wrap any C code around is super helpful - a pretty strong type system! No more annoying implicit conversions from any type to a bool, error prone implicit int <-> float conversions etc. I probably forgot many points, but well. The truth is of course, many languages could have worked for me, but the time I spent with Nim in the beginning was just super pleasant. [1] https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer
  - V1ndaar 7y ago
    Sorry for the missing line breaks in there, typed this on my phone. And for some reason my edits don't stick. :|
  - ziotom78 7y ago
    I followed the opposite route: tried Nim and liked it a lot, then switched to Julia. Perhaps my typical usage of a scientific language is quite different from yours. In my case, what drove me away from Nim was the fact that even small features of the language keep changing in no controlled waya. It was 2014, and commits related to some obscure feature were subtly changing the behaviour of apparently unrelated stuff. Julia changed a lot in the last years, but in a very controlled way, and always sticking to semantic versioning. In 2014, Nim 1.0 was said to be behind the corner, yet only a few weeks ago the first RC for version 1.0 was released (Nim 0.20), and it still broke some basic stuff like bitshift operators. Moreover, the lack of scientific libraries in Nim was more severe wrt Julia. Sure, writing C bindings in Nim is easy, but it is not a zero-effort job: you have to properly test them to check that types get converted correctly, and you have to write some documentation. Some guy is currently checking the quality of Nim libraries [1], and he gave very low scores for a few libraries of mine (rightly so, IMO, e.g., [2]) because they lack documentation. [1] https://forum.nim-lang.org/t/5092 https://forum.nim-lang.org/t/5092 [2] https://github.com/ziotom78/nimcfitsio https://github.com/ziotom78/nimcfitsio

SiempreViernes 7y ago

Ah, axion searches! Who said you can't get paid for staring at a wall? How come you didn't go with Julia? (or Fortran for that matter?)

V1ndaar 7y ago
Haha, well you can get payed for it, but you won't be payed well. It's hard to give an easy answer for that. But let's step back a little: I played around with Julia several years ago. I don't know when exactly, probably in 2015 (?). Back then I thought of it as a faster python for science. Many things I would use python for back then I could have done in Julia too. Others I couldn't though, because the eco system was still too small. And while Julia was somewhat faster for the things I tried, it wasn't amazingly faster. My interest in the language dropped sometime after that. But still, I felt like it was a language targeted specifically to scientists. Many things I wanted from my analysis framework however were outside that bubble I felt. I didn't simply want to write a faster "analysis script". I do realize however, that the language has evolved a lot and I'm happy it's finding acceptance! Fortran on the other hand, I never really considered. I suppose modern Fortran is a pretty good language though. So why did I choose Nim then? It gave me: - the ability to produce standalone binaries I could just put on any data acquisition pc without a hassle (well ok, be careful about old glibcs) - it's fast, and I felt right at home syntax wise coming from python - the community is amazing. The first time I entered Nim's IRC channel I noticed Araq, the creator of the language, answering random people's questions! In general the community allows for a super quick feedback loop to learn the language - it's a pretty concise language. The whole manual can be read in less than a day - having written some Clojure, I loved the idea of a powerful macro system - after seeing mratsim's arraymancer library [1] I was happy to 1) have a numpy substitute and 2) thought if one person could write such a great library in O(1 year) it must be a pretty awesome language to work with :) - being able to trivially wrap any C code around is super helpful - a pretty strong type system! No more annoying implicit conversions from any type to a bool, error prone implicit int <-> float conversions etc. I probably forgot many points, but well. The truth is of course, many languages could have worked for me, but the time I spent with Nim in the beginning was just super pleasant. [1] https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer
- V1ndaar 7y ago
  Sorry for the missing line breaks in there, typed this on my phone. And for some reason my edits don't stick. :|
- ziotom78 7y ago
  I followed the opposite route: tried Nim and liked it a lot, then switched to Julia. Perhaps my typical usage of a scientific language is quite different from yours. In my case, what drove me away from Nim was the fact that even small features of the language keep changing in no controlled waya. It was 2014, and commits related to some obscure feature were subtly changing the behaviour of apparently unrelated stuff. Julia changed a lot in the last years, but in a very controlled way, and always sticking to semantic versioning. In 2014, Nim 1.0 was said to be behind the corner, yet only a few weeks ago the first RC for version 1.0 was released (Nim 0.20), and it still broke some basic stuff like bitshift operators. Moreover, the lack of scientific libraries in Nim was more severe wrt Julia. Sure, writing C bindings in Nim is easy, but it is not a zero-effort job: you have to properly test them to check that types get converted correctly, and you have to write some documentation. Some guy is currently checking the quality of Nim libraries [1], and he gave very low scores for a few libraries of mine (rightly so, IMO, e.g., [2]) because they lack documentation. [1] https://forum.nim-lang.org/t/5092 https://forum.nim-lang.org/t/5092 [2] https://github.com/ziotom78/nimcfitsio https://github.com/ziotom78/nimcfitsio