Is this sad only when people have to talk about their pain points?
Not the language itself (which I love) I can write code so quickly in it, and I didn't struggle for very long with fighting the borrow checker, which seems to turn so many other people off.
It's everything else. Long build times. "Modern" dependency management, which seems to mean package X only works with 0.6.x of package Z and package Y only works with 0.7.x of package Z and the current version of package Z is 0.8 and has a bugfix you really need. Though I should say that very few languages with a central repository don't have this problem; you make it easy to depend on libraries with unstable APIs and everyone will rush to do it.
I totally agree that nailing everything down to the one particular minor rev causes way more problems than it solves. The worst part is I'm pretty sure you can be more general (give me version 3, or >3.3.1, not =3.3.1) but all of the automatic tools and online guides default to nailing it down to exactly one version because they're so damn paranoid about API changes.
I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies, you don't typically see programs pulling in dozens or hundreds of modules the way you do in node projects. But it's remarkable how many old Perl programs can still pull the dependencies and start right up.
The fact that CPAN avoids this makes me think it's largely cultural. At least some of it may be that CPAN came of age in an era when internet access was less reliable and slower.
Some of it is also that development "in the open" has become more the norm. When releases are rare and only contributors have VCS access, then there are fewer opportunities to depend on unstable interfaces.
I was surprised when I installed `git` and it pulled a couple dozen Perl packages from the distro repo.
There's definitely something to be said about Linux distro maintainers/packagers being sort of middlemen that help enforce compatibility for popular Perl (or Python2, etc) packages.
That is, there is a nonzero amount of greybeards between the developer and random end user, which cannot be said for your average npm or pip package.
Probably because CPAN existed before SemVer.
Given that patch version bumps of a dependency might break a project, I think giving up on the SemVer paranoia would be the best solution.
If a dependency breaks you just release a new patch release of your software with the version pinned before the breaking version. Add a field to the package manager to hint at the dep solver that it should never downgrade to remove that depedency because it was added due to a breaking change to sort of make it retroactive.
And the failure of many projects to go 1.0 because of paranoia about breaking changes and therefore the failure of SemVer should really be more widely discussed.
It's important to recognize pain points so we do not become complacent with low quality developer experiences. Worse, complacency with software lifecycle at scale - will our product deploy on a cluster? Will our software be maintainable 5 years from now?
Better we look at the pain points now than accept a poor DX for years to come.