Tbf, both C# and VB use NuGet. Which also functions as the command line software installer for Windows in general. So it is kind of what you are looking for.

Perl CPAN has been snubbed.

Trading convenience and time-to-relrase with safety and long-term stability, by lego-ing kitchen-sink packages with glue code together. In short, mostly a thing of business needs and the JavaScript generation.

Don’t get me wrong; libraries are useful.
But the way the popular languages handle them – trusting foreign code by default and importing 90% unused code – is dangerous.

Example, Rust starter tutorial for a cli application: “import clap”. ca. 15 packages depency, but it has

• plugins
• theming engine
• fuzzy find
• suggestions (did you mean)

Great start, no? basiclaly importing it’s own application. Instead of teaching, how to parse std::io. Trust us bro, we do the right thing (and also all our 100 dependencies).

C and C++ are the only exceptions I can think of, off the top of my head; libraries are managed by, and coupled to, the operating system

For C/C++ there’s conan, vcpkg, and whatever Redhat calls their scl system these days. I know there’s more, but those are the ones I can remember off the top of my head. You could argue that podman serves in this capacity to some degree.

Simplest answer: it enables programmers on any variation of an OS to get code. If I’ve got a python requirements.txt, getting those requirements installed is the same on any system I’ve got an appropriate python version. The designers of the languages effectively deemed that an important goal and explicitly put in the effort to include package management, in at least most of your listed cases.

Because it’s one central repository regardless of distribution or even OS.

I couldn’t imagine having to build packages for every single package manager and OS whenever I push a new version of my JS library.

One thing also important here is that not all os / distro package managers let you pin or choose versions. When you update you update. Software projects often lock dependencies to specific known working versions, which package managers generally support

I wanna tackle the question „What’s the benefit?“ first. Imagine one package manager with one repository to serve multiple languages. Now I want to install a library for my rust project and I include a Python library (maybe by accident, maybe intentionally). What’s supposed to happen? Rust can’t call into Python so it can’t work.
So ideally libraries would have to be scoped to specific languages, and now we’re almost back to the original situation but with a worse package manager.

And what if I want to include a C++ library in Rust? If that library isn’t heavily using external C then the ABIs are going to be incompatible, and I still can’t use the library properly.

Does that fictional generic package manager also have to ensure compiled languages compile in a ABI compatible manner automagically?

And what is the OS package manager gonna do when you have two separate projects requiring two different versions of the same dependency?