I maintain a fairly complex computational project about 10 years now... I do not see these problems and I would not want to do this in Rust (after studying it for a while). Mostly I like me extremely short compile times. The huge amount of dependencies the cargo-style of development tends to pull in and the instability of Rust would also still worry me a lot.
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
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.
Just 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.
