Hacker News Reader

Comment by conradk | Hacker News Reader

That's great ! Definitely a argument in favor of Perl. Being more used to NPM (for Javascript) and knowing that you can (or at least you could) unpublish a package, I'm glad to see that with Rust, I won't have to worry about dependencies disappearing for no reason.

View on HN

CPAN as an argument in favor of Perl? That's a new one on me...

Isn't CPAN for Perl ? I don't actually know CPAN. All I'm saying is that having a package manager that doesn't allow removing packages is an advantage IMO.

Yes, CPAN is for Perl. I'm just saying I've never heard of a particularly good experience with CPAN.

CPAN packages can't really be uninstalled (http://stackoverflow.com/questions/2626449/how-can-i-de-inst...) and seem to be unnaturally prone to dependency hell.

I've had particularly good experiences with CPAN. Long enough ago I don't remember the details, and I wasn't doing anything exceptionally complicated, but I remember being favorably impressed and able to get my work done without hiccups.

Same here. Its infrequent that I go to CPAN and I am unable to find a package that will help along.

The concern about running the entire test suite on module installation really isnt a problem if you think about. Additionally you are able to force the install if it fails on account of a test.

CPAN dependency resolution seems worse than with other package managers for two reasons. First, CPAN prefers to install the most recent version of a dependency (rather than pinning to a specific version). Second, the default CPAN client behavior is to run the entire automated test suite for every distribution it installs.

While that behavior feeds back into improved quality for responsive maintainers, it takes additional time during installation. When combined with point #1, it can make dependency chains seem more fragile.

Reply on news.ycombinator.com