The primary would be the fact that Rust does not have a standard of any form and all builds are static means you are effectively required to use cargo to distribute software.
The TOML configuration format is weak and it's easy for things like namespaces and features and optional dependencies to get severely complex rather quickly to the point that it's easy to introduce subtle bugs or create a fragile configuration.
The requirement to use semver, which may work for a lot of projects, but is not necessarily the best when dealing with software that deals with regulatory compliance issues. The version number is sometimes a product of multiple considerations. Unless you want to publish a page that helps users understand how versions map onto regulatory calendars.
The fact that "semver tricks" even exist.
The cache is poorly designed and what you get by default lacks several important features that require third party crates to solve. Even basic things like safely clearing the cache or sharing the cache across workspaces. Last I looked there were some unstable cargo features which spoke to this but weren't finished yet.
The way resolution works. The fact that multiple different versions of the same crate can be pulled into your build without any warning during build. You have to stay on top of that yourself and given the depth of some dependency trees I find that this gets skipped entirely in a lot of released software.
Registries outside of crates.io are hard to implement and have several specific challenges that limit the utility of even using this feature.
This is just cargo. The entire language and ecosystem simply aren't ready for primetime. It works for distributing software in limited circumstances but is overall of very low quality when compared to other build systems and user expectations surrounding their distributions and how software is installed into them.
Which are all solvable problems. Unfortunately the Rust community generally seems to see itself as beyond these problems and does not dedicate any significant effort into solving them. Which is fine, but, also means saying you want to push Rust to be "foundational" is an absurd statement to me. Hence "cart always before the horse."
Finally, as demonstrated here, the Rust community simply cannot handle any criticism. Which is probably why they ignore the "foundational issues" in their language. It's become an echo chamber of mostly bad ideas. You don't have a systems language in Rust, you have a niche application language, which is simply not worth the effort to use in my opinion.
Which is an honest opinion. Flag me and downvote me if you want, although I don't see how what I did here was particularly rude or disruptive, just opinionated. I had the "wrong" opinions I guess. So I will not waste further time contributing to this discussion and the rustacieans can go back to ignoring all outside influence while existing in their niche. Just don't ask yourself "why don't more people use Rust?" We keep trying to tell you. You said you want a "foundational" language. This is part of that.
> Unless you want to publish a page that helps users understand how versions map onto regulatory calendars.
Why would a changelog/release log with dates not work?
> The fact that "semver tricks" even exist.
How would you propose to solve the problem semver-trick solves, then?
> The way resolution works. The fact that multiple different versions of the same crate can be pulled into your build without any warning during build.
What would your preferred solution be if you/your dependencies depend on incompatible versions of a library?
> It works for distributing software in limited circumstances but is overall of very low quality when compared to other build systems and user expectations surrounding their distributions and how software is installed into them.
What are some better build systems you think Cargo devs might want to learn from?
> Finally, as demonstrated here, the Rust community simply cannot handle any criticism.
I suspect your comment might have done better if not for the last two sentences. At least from what I've seen Rust criticism on HN does just fine, especially if explained thoroughly. Insults fare somewhat less well.
Some of your points are somewhat valid but none of this is that big a deal. With most Rust projects cargo build just works out of the box. The uniformity of experience is very high value.
> It works for distributing software in limited circumstances
I don't know what that means.
> You don't have a systems language in Rust, you have a niche application language
Okay.
> which is simply not worth the effort to use in my opinion.
You're welcome to hold that belief. Meanwhile I'll continue to build systems software in Rust that delivers real value to real users in ways that are impracticable or impossible in any other language.
The TOML configuration format is weak and it's easy for things like namespaces and features and optional dependencies to get severely complex rather quickly to the point that it's easy to introduce subtle bugs or create a fragile configuration.
The requirement to use semver, which may work for a lot of projects, but is not necessarily the best when dealing with software that deals with regulatory compliance issues. The version number is sometimes a product of multiple considerations. Unless you want to publish a page that helps users understand how versions map onto regulatory calendars.
The fact that "semver tricks" even exist.
The cache is poorly designed and what you get by default lacks several important features that require third party crates to solve. Even basic things like safely clearing the cache or sharing the cache across workspaces. Last I looked there were some unstable cargo features which spoke to this but weren't finished yet.
The way resolution works. The fact that multiple different versions of the same crate can be pulled into your build without any warning during build. You have to stay on top of that yourself and given the depth of some dependency trees I find that this gets skipped entirely in a lot of released software.
Registries outside of crates.io are hard to implement and have several specific challenges that limit the utility of even using this feature.
This is just cargo. The entire language and ecosystem simply aren't ready for primetime. It works for distributing software in limited circumstances but is overall of very low quality when compared to other build systems and user expectations surrounding their distributions and how software is installed into them.
Which are all solvable problems. Unfortunately the Rust community generally seems to see itself as beyond these problems and does not dedicate any significant effort into solving them. Which is fine, but, also means saying you want to push Rust to be "foundational" is an absurd statement to me. Hence "cart always before the horse."
Finally, as demonstrated here, the Rust community simply cannot handle any criticism. Which is probably why they ignore the "foundational issues" in their language. It's become an echo chamber of mostly bad ideas. You don't have a systems language in Rust, you have a niche application language, which is simply not worth the effort to use in my opinion.
Which is an honest opinion. Flag me and downvote me if you want, although I don't see how what I did here was particularly rude or disruptive, just opinionated. I had the "wrong" opinions I guess. So I will not waste further time contributing to this discussion and the rustacieans can go back to ignoring all outside influence while existing in their niche. Just don't ask yourself "why don't more people use Rust?" We keep trying to tell you. You said you want a "foundational" language. This is part of that.
anyways....