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.
> Rust is a language for people who want to be _seen as programmers_. Not people who _actually love programming_.
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?
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)
> How about get an actual published language standard? How about get more implementations of it? How about fix the utter mess that is cargo?
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".
Consider a programming language that self describes as young and growing, for-fun, silly idea taken too far, we'll see where it goes, no particularly lofty goals at the moment, etc; in this case you're not asking anything of anyone else and reasonable people will be happy to let you have your fun.
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 don't think I quite agree with the power/responsibility analogy. To me, "power" the way its used in the quote implies some kind of control over something/someone else. That's not really the kind of relationship I see between a programming language and the software that uses it - if I write a program in C++ I don't really view the C++ committee as having "power" over my program. In addition, it's not something a spec really does anything to address - you can be plenty irresponsible with your (hypothetical) power with or without a spec
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.
Theoretically correct, but worse is better - consider how many things we could have asked of C or javascript before they become standards.. Practically, a spec is something to prioritise alongside all the other things we wish for
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.
Out of curiosity, why do you think it’s the best? I can imagine where it can be better than e.g. Maven, but Rust-centric and Java-centric developer workflows are so different that those things probably don’t matter much.
