Languages should not have a package management system. They all have a all the world is my language blindspot and fail hard when you have anything else. Sometimes you can build plugins in a different language but they still assume the one true language is all you want.

package management belongs to the os - or at least something else.

don't get me wrong, package management is a real problem and needs to be solved. I'm arguing against a language package manager we need a language agnostic package manager.

I think C++ is a living proof that not having a standard tooling around the language makes the language a complete pain in the ass to use, with any other language that does standard package managing/tooling out of the box, I can just pin the versions, commit a file to the repository, and on any computer that I'm working on I just issue a single command and everything is handled for me; meanwhile one of the C++ projects I've been working on, it turned out that I cannot build it on my server because one of the libraries I'm using only worked with clang17 which my desktop OS provides but the Debian I'm using on my server is shipping with clang16, and the library was not compatible with the earlier version of some C++ implementation, meanwhile Arch on my desktop updated to clang18, which also broke the library in some fashion, so now I'm sitting here with two systems, one where I want to deploy my software, and one where I want to develop the software, both of which are completely defunct and unable to build my project anymore; now I have to figure out how to build the specific version of clang on both systems and ensure I override a bunch of environment variables when configuring the builds on both of these systems, and then do the same on every new computer I'm developing/deploying on - with a proper tool I could just tell the project file to "use this compiler with this version with this standard" and things would just work. Some people will tell you "yeah bro just use docker with this and that and you will have a reproducible build system everywhere", but the thing is - I do not want to learn a completely unrelated tool and spend hours writing some scripts just to be able to continue working on my project when in any other programming language (like Go, Rust, JS), I can just install the runtime, clone the repo, run a command, and everything is handled for me seamlessly like it should be in 2024.

> package management belongs to the os

Os package managers do a fundamentally different task than dependency management tools used in development.

They ship a bunch of applications and the libraries you need to run the applications.

If you need different version of libfoo than e.g. Firefox does, you're out of luck.

Need to support a customer with an older release which needs a different version of libfoo? Not gonna happen.

Unless you're talking about Nix or Guix, your OS package manager is not a substitute for a dependency management tools.

Specifications for package interchange are absolutely essential, which is distinct from language endorsed package managers.

Python doesn't have a language package manager, you're free to use pip or poetry or uv or whatever, but it does have PEP 517/518, which allow all Python package managers to interact with a common package ecosystem which encompasses polyglot codebases.

C++ is only starting to address this problem with efforts like CPS. We have a plethora of packaging formats, Debian, pkg-config, conan, CMake configs, but they cannot speak fluently to one another so the package ecosystem is fractured, presenting an immense obstacle to any integration effort.

Interesting point, and I'm included to agree with your main point. I don't think the OS level is preferable, however:

Point 1: I do not want my program to only run on only one OS, or to require custom code to make it multi-platform.

Point 2: What if there's no OS?

This sets up an untenable N*M explosion:

Will the GhostBSD maintainers pin the right version of Haskell's aeson package?

Will the Fedora Asahi devs stay on top of the latest Ocaml TLS developments?

Will MS package PureScript's code for DOM manipulation?

But like…why?

Let’s say we make a “thing” which contains packages for all participating languages.

98% of the time, aren’t users just going to go “filter down to my language” and just continue what they’re doing, except with a somewhat worse overall experience, depending on whatever the “lowest common denominator” API + semantics we use for this shared package management solution.

Multi-language build systems already exist, which happily serve the needs to those projects which find themselves needing cross-language (+distributed) builds. Could there be some easier versions of these? Sure, but I don’t feel like “throw everyone in the same big box” is the solution here.

I think the term "package management system" is a bit over broad a term to talk about.

If we are talking about global shared dependencies, sure it may belong in the OS.

If we are talking about directly shared code, it may as well belong in the language layer.

If we are talking about combining independent opaque libraries, then it might belong in a different "pseudo os" level like NPM.

> package management belongs to the os

It clearly doesn't except if you're a fan of dll hell and outdated packages.

Disagree completely. OS package managers are one of the biggest sources of problems.

Basically, once you have an OS level package manager, you have issues of versioning and ABI. You have people writing to the lowest common denominator - see for example being limited to the compiler and libraries available on an old Red Hat version. This need to maintain ABI compatibility has been one of the hugest issues with evolving C++.

The OS package manager ends up being a Procrustean bed forcing everything into its mold whether or not it actually fits.

Also, this doesn't even have the issue of multiple operating systems and even distros which have different package managers.

Rust and Go having their own package managers has helped greatly with real world usage and evolution.

Agreed. At least, languages should not require its own package management system to be used. There should be a way to invoke the compiler or interpreter without involving that language's own package management system, so that something else (like Bazel) can build on top. Fortunately, most common languages are all like that. You can invoke rustc without cargo. You can use python without pip. You can use javac without maven.

Honestly I don’t know why more languages don’t just adopt e.g. npm, maven or NuGet. They’re largely language independent at the binary level anyway.