I was browsing the thread on why LoopVectorization.jl is deprecated, and I came across LoopModels, which is a successor to LoopVectorization.jl, and this made me wonder if one should be writing general purpose libraries in Julia (even if domain specific) or just go for C/C++/Rust/Zig or something like that.
For my specific use case: I’m working on a package currently for doing continuous time monte carlo simulations on Potts models, and I’ve not faced any issues thus far, but this is mostly for my own work. I would like to make this available as a package once ready, and I’m fairly certain that doing so in Julia would be good enough. But I’m not super experienced in developing widely used software, and a lot of my work is and will be in computational physics, so should I learn to develop my code in the aforementioned languages? So far I’ve been solely using Julia and I do love it, but I am just looking for anybody kind enough to share their opinion/experience.
I’d say that LoopVectorization is a very unique sort of library. It’s effectively a compiler plugin — you’re explicitly asking for a particular compilation strategy. The challenges there are quite unique.
There can be a tension between performant Julia and “friendly” Julia, but that’s a very different sort of problem than building the tooling for maximum performance at all costs.
In any case — it’s great that you’re enjoying it and I’m glad it’s working for you!
The context here is that LoopVectorization is not an ordinary library, but a library that attempts to do very low-level things with the compiler — basically to create a new compiler-optimization pass for other code. The argument was that, if you want to hook into the compiler at that level, you should really be interfacing with the compiler directly, rather than indirectly through Julia’s high-level language. And since our low-level compiler (LLVM) is written in C++, to access it directly you really need to be writing in C++.
I don’t think this applies to ordinary Julia packages/libraries (of which there are already many thousands).
Not everyone in the world agrees about this stuff, and some people do build things in julia and then decide to use other languages, and this can happen for a variety of reasons.
Sometimes julia has a fundamental weakness in a specific area (or is just immature in that area)
Sometimes the author of the package decides that they just don’t like julia as a language
Sometimes there are issues of accessibility / sharing the library with certain key people that make it more attractive to use one language or another
etc
On the other hand, there’s lots of projects that have started in other languages and then moved to julia. ITensors.jl for instance used to be in C++ and then moved to julia. The DifferentialEquations.jl stuff started out very early on in Matlab (if I recall correctly?) and then moved to julia.
Julia has real strengths and things to offer, especially for scientific numerical projects like the one you’re describing. If things are working out well for you currently, I wouldn’t worry about it too much. And if problems do come up, I think the community here would be more than happy to try and help you work through them!
Personally, I definitely wouldn’t want to do that kind of work in C++.
Why do you use Julia? Why have a Julia and C++ version?
ITensor was originally written in C++ around 2010 before Julia was available. C++ was a good choice and continues to be an strong language for high-performance computing.
We ported ITensor completely to Julia to benefit from Julia’s high performance (it is a compiled language), its expressivity (it offers a robust type system as well as a dynamic, generic programming experience), while avoiding the common “two-languge problem” of using a slower interface language with a high-performance back-end language. The choice of Julia has been very successful for us and delivers both high performance and productivity. It is also easy to call Julia code from other languages such as Python.