[flagged]
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....
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.
> 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.
Nice gatekeeping. I happen to actually love programming and I pick up languages quickly. Rust has been a fresh breathe of air and I can’t ever see myself going back to the horror show that is the masochism of C++.
> How about get an actual published language standard?
https://rustfoundation.org/media/ferrous-systems-donates-fer...
But also a language standard means fuck all to me. C and C++ keep generating them and the language doesn’t seem to be getting meaningfully better.
> How about get more implementations of it?
Why is this important? Python has one central implementation that everyone relies on. So does Java. C++ doesn’t and is plagued by every project either trying to support N platforms across M compilers or just pick clang everywhere (but still be stuck with having unnecessarily complicated platform specific code).
> How about fix the utter mess that is cargo?
What’s the utter mess? I’ve been using it for a while and haven’t observed anything obscenely problematic. Significantly easier than anything in C++ for sure (maybe Conan but I’ve not seen anyone actually using that in the wild)
I think these arguably also warrant a "is this putting the cart before the horse?" analysis. I think the value of all of those are pretty debatable (especially in different fields), and I don't think it's at all obvious that Rust would have done any better had it devoted more energy to those earlier in its life.
Also, I think that the article is technically compatible with working on those points anyways?
> Let's replace everything else.
I don't think that's what the article is trying to say? "Targeting" here seems to be more in the vein of "usable for", like "target" in "this language targets this use case".
As they say, with more power comes more responsibility. Targeting foundational software is aiming for more power; complaining that writing and conforming to a spec is annoying is shirking the corresponding responsibility.
If you are aiming to be the foundation of an entire industry it doesn't seem unreasonable to ask for some specifications.
I'm not sure I'd agree that a programming language has a duty to produce a spec either, whether it's for foundational software or not. Outside of legal/regulatory requirements, I think a hypothetical "perfect" low-level/systems language would be used no matter whether it had a spec or not simply because it was the best tool for the job. In that sense the language devs' "responsibility" would simply to make the language as suitable as possible for users' software. Of course, legal/regulatory requirements throw a wrench into that thought experiment, but hopefully the point made it across.
None of that is to say that asking for a spec is unreasonable, especially if you're required to have one to use the language. I'm just more on the skeptical side as to its overall importance.
Cargo is currently the best first party language package manager on the planet. It learned from all of the other systems that came before it.
Cargo could use a few improvements, like namespaces and hermetic, repeatable builds, but it's one of the nicest infrastructure pieces we have in any language.
No other language in the top 20 has anything like Cargo. The language needs to be designed hand in hand with its package manager, so it'd be hard to bolt a Cargo onto other established languages.