4 ms·
Some of these are personal choices. Some of them are not. E.g. look at the blis project, compilation on windows is still problem. On the dependency issues, I w
by gauge_field 2y ago
Some of these are personal choices.
Some of them are not. E.g. look at the blis project, compilation on windows is still problem.
On the dependency issues, I would disagree. Firsly, large amount of dependency (especially if you working on computational project e.g. on a university cluster) is not really an issue, because in the projects I worked with C++/python bindings, we already used alot of python bindings and dependencies from python ecosystem. It is just the nature of experimental projects/numerical. Limiting number of dependencies for numerical projects (e.g. simuation of physics sytem) is an very rare example given the how little academia care about the software develop, they pull whatever helps them (Nothing wrong with that since they have other things to care about than software quality).
Secondly, It just depends on the number of dependencies you pull, you have the option not to include and write it yourself, which is what C projects tend to do. It is trade-off. Given, how east it is to manage other things in rust-up (e.g. tooling versioning),
I prefer this one.
I think this is more of philosophical difference: modern tooling (where you use tools like cargo/pip with declarative simple config api) vs make (where you do it more by yourself)
There can be some issues with dependency, e.g. breaking change. But, these are not unsolvable problems. If you choose you dependencies correctly, I would prefer having to manage dependency version than to write it myself (Again you can write it yourself if you want). Also, these issues are really rare.
I dont know about instability of Rust itself and where you are getting this claim from. Rust promises backwards compatibility and uses tools like these to make sure it: https://github.com/rust-lang/crater https://github.com/rust-lang/crater
Maybe you are talking about MSRV as semver breaking change. There has been alot of discussion about this, you can read it up as to why the choice made.
Regarding compilation time, you have to be more careful about what features you use (not spreading traits throughout your code) using incremental compilation, see: https://matklad.github.io/2021/09/04/fast-rust-builds.html https://matklad.github.io/2021/09/04/fast-rust-builds.html
Another one is lack features: E.g. generics (That is why I'd prefer using C++ than C). But, that is one of the features of C, not a disadvantage.
- gauge_field 2y agoJust to add, there are tools in C/C++ that addresses some of these issues. For instance, I use meson as much as I could, and their project is really makes it smoother. I feel like it should have been used more in the ecosystem.