My email is what finally moved the committee and GHC devs on including Stack with the Platform and on some other decisions concerning the website.
Like I said, not all the downsides may be applicable to how Cargo works or what aturon has in mind, but please don't cite it as an exemplar of anything.
That's quite the email! Without a TLDR, I'm not sure how to assess how susceptible Cargo is to those problems. My personal experience with Rust has been that there are very few instances where versioning or dependency issues cause me problems. The specific instances I have dealt with would be resolved by the proposal in the blog post (trying to use a version of serde which differs from what another core-ish library wants to use, etc.).
IMO the root problem is that the Haskell Platform is both a set of curated packages and a bandaid for the fact that so many things Haskell are hard to build/install for no-good reason.
On the first front I guess it's alright (but stackage is better) and on the second front it's totally inadequate—maybe even harmful in that it probably made the problem just less painful enough to spur procrastination.
I think most of this lesson doesn't apply to rust, but still good to be aware. It certainly gave me a strong eversion to course-grained dependency management as a bandaid.
>so many things Haskell are hard to build/install for no-good reason.
Were. Were hard. It's quite fine now with Stack. I know users of all kinds of languages that all miss Stack when they're working on their non-Haskell projects.
Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cutting edge stuff like Nixpkgs) and Stack is by far my favorite.
EDIT: To elaborate on why I like Stack:
+ Fully declarative. I don't run commands to edit my Stack environment, instead I modify the relevant stack.yml file. This means that the current environment can always be easily examined, committed to Git, etc.
+ Easy NixOS integration which means I can also describe the non-haskell dependencies for a project, and enforce that _absolutely_ nothing else on my system gets used. This is amazing.
+ I like that it uses Stackage by default, and that I can pin projects to LTS Stackage releases. This means that many users of my projects will probably already have most dependencies installed -- especially cool for small things like tutorials where users won't have the patience for long build times.
+ It reuses the already existing `.cabal` file format so it's easy to make libraries compatible with cabal-install, the other package manager in the Haskell ecosystem.
Hey! So I'm deeply appreciative towards cabal-install for historical reasons. The situation before cabal-install was . . . not the best (https://www.gwern.net/Resilient%20Haskell%20Software) so I think we can credit cabal-install with a lot of the success the ecosystem has had over the last decade.
That said, nix-style builds don't actually address my issues with cabal-install. My (very personal) preference is to always have the current dependencies being used reflected exactly in a local file. I picked up this attitude from NixOS, but it's an extremely useful way of doing things -- the knowledge that as long as I don't lose that file I can always rebuild my current environment exactly is just too awesome.
I think that if you need to track version bounds as well (say you're developing a library) they should be kept in a separate file, and you should always have a master file that describes what you're currently using locally. Happily this is exactly what Stack does with my-project.cabal and stack.yml.
That said, I appreciate that others like cabal-install, so I do what I can to make my code easy to use with both package managers (the main thing is keeping aggressive upper bounds on the few libraries I maintain, which especially helps cabal-install users since they do dependency solving more).
My email is what finally moved the committee and GHC devs on including Stack with the Platform and on some other decisions concerning the website.
Like I said, not all the downsides may be applicable to how Cargo works or what aturon has in mind, but please don't cite it as an exemplar of anything.