Hacker News Reader

Comment by 38 | Hacker News Reader

> No package manager to distract you

What decade am I in? This is not optional any more. Hard pass.

Definitely a feature to me.

I don't have to be worried that a 3rd party library without dependency begins to have 30 transitive dependencies which now can conflict with other diamond dependencies.

I need my dependency tree to be small to avoid every single factor of friction.

Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns).

>Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns).

Sounds like you're biased.

https://archlinux.org/packages/extra/x86_64/gnome-shell/

gnome-shell > accountsservice > shadow > pam > systemd-libs > xz > bash > readline > ncurses > gcc-libs > glibc

and I didn't even try finding the longest chain...

Package managers are such an odd thing from a social perspective.

You'll see cases like NPM and to a lesser degree Cargo where projects have hefty dependency graphs because it is so easy to just pull in one more dependency, but on the other side you have C++ that has conan and vcpkg but the opinions on them are so mixed people rely on other methods like cmake fetch package instead.

I appreciate having tools that let me pull in what I need when I need it, but the dependency explosion is real and I dunno how to have one without the other.

If you require end users (and possibly libraries? IDK) to manually specify every transitive dependency of a dependency (but not hard-code/vendor it), this should act as a forcing function to reduce transitive dependency explosion in libraries (because it would degrade user experience). I'm not sure if users should have to update every dependency by hand (this discourages updates which can cause security bugs to persist, but automatic updates makes supply-chain attacks easier; AUR helpers generally diff PKGBUILDs before committing them, which partly protects against PKGBUILD but not source attacks, and even distros did not protect against the xz attack).

Another factor is that updating C++ compilers/stdlib tends to break older libraries; I'm not sure if this is any less the case in Rust (unclear? I mostly get trouble with C dependencies) or Python (old Numpy does not supply wheels for newer Python, and ruamel.yaml has some errors on newer Python: https://sourceforge.net/p/ruamel-yaml/tickets/476/).

To the best of my knowledge (I only dabble in Rust) there aren't often too many breaks unless code accidentally relied on soundness bugs which Rust makes 0 promise of retaining to keep code working.

This is optimizing for the wrong metric, IMO. If I look at the dependency tree of a fairly hefty project in rust, mostly what I see is the same amount of code as an equivalent project in C/C++, just split into multiple packages instead of bundled up into one source tree. Which ironically means packages tend to be able to pull in the minimal amount of excess code through transitive dependencies. All that you'll do with this kind of incentive is push packages into effectively vendoring their dependencies again.

This reminds me of this article https://wiki.alopex.li/LetsBeRealAboutDependencies

It's incredible how much stuff some C projects vendor

For recreational programming purposes (and sometimes professional depending on the domain), they really are a distraction.

The existence of a package manager causes a social problem within the language community of excessive transitive dependencies. It makes it difficult to trust libraries and encourages bad habits.

Much like Rust has memory safety benefits as a result of some choices that make it difficult to work with in some context, lack of a package manager can have benefits that make it difficult to work with in certain contexts.

These are all just tradeoffs and I'm glad "no package manager" languages are still being created because I personally enjoy using them more.

I'd rather have my languages focus on being a language and use something non-language-specific like nix or bazel to situate the dependencies.

Sure, the language maintainers will need to provide some kind of api which can be called by the more general purpose tool, but why not have it be a first class citizen instead of some kind of foo2nix adapter maintained by a totally separate group of people?

There's no need to have a cozy CLI and a bespoke lockfile format and a dedicated package server when I'll be using other tools to handle those things in a non-language-specific way anyhow.

A tool like Nix also makes for an end result that's far more auditable than the latest and greatest language specific package manager of the day.

I am on the complete opposite side here. I detest language specific package managers for many reasons.

One of the non-goals is “to be useful to anyone,” after all.

I like this language, it shares my aesthetics.

It seems like the possible outcomes are:

(a) nobody uses the language, so a package manager doesn't matter OR

(b) people use the language, they will want to share packages, then a package manager will be bolted on (or many will, see python)

Seems like first-class package manager support (a la Rust) makes the most sense to me.

Big feature for me. In frontend dev, 3k dependencies in a hello world app is considered normal. In systems, a free-for-all dependency graph is a terrible plan, especially if it's an open ecosystem. NPM, Cargo, etc are good examples.

This is also why systems people will typically push back if you ask for non-official repos added to apt sources, etc.

Reply on news.ycombinator.com