That strikes me as another C-ism that didn't deserve to be carried forward into a 21st century language.

There's a reason we call it "dependency hell" and not "happy fun fussing with dependency version conflicts among projects that are completely unrelated except that you happen to be using the same computer to work on them time."

The state of the art in package management could be considered Nix and Guix and those are both operating system level package managers and thats why they are better than npm or pypi or cargo, as the aforementioned language specific package managers _dont_ handle dependency hell as native dependencies exist. they all have the same problem as 'they work on my computer' and also encourage this ecosystem of thousands of micropackages, which in a thread so focused on security seems a little ironic given there is no way to guarantee all of those dependencies are made by good actors without a lot of vetting that just is not happening.

I've never had a "works on my machine" bug when dependencies are managed per project. The only time I have ever had them is with global/os-level dependencies. And I've used cargo/npm a lot in the last few years.

I do agree on the micropackages.

What I keep daydreaming of is a package manager that resolves and download packages, but doesn't automatically grab transitive dependencies. I don't even want it saying, "Hey, we need to grab these 15 other ones, too, is that OK?" I don't want to hide the pain of huge dependency graphs like that; I want to feel it acutely. Give me an error message saying, "Oops I couldn't add FancyPackage because it depends on X, Y and Z transitive dependencies," and send me on a fetch quest. And I want the whole community around the language I'm working in to feel it acutely like that. That way we're all in the same boat, and collectively incentivized not to create the problem in the first place.

That is on the library developers to settle out. Keeping your library API stable requires the mind of a genious and discipline of a monk.

Now, keeping your language design stable and backward-compatible is a no brainer. Given that, it's possible to handle "dependency hells" simply by building from source.

Hare is designed to be ultra conservative, so you don't have to worry about dependency hells. Features are in code, not builtin into the language.

It is a win-win situation.

That's a great way to make a program work only on specific distros.

Seems it fits Hare perfectly then, as one of the explicit goals of Hare is to only support non-proprietary OSes.

I'd guess it does the opposite?

If I'm writing for a proprietary OS, that's probably Windows or OS X. Both of which give me a more stable target to aim at when it comes to what dependencies I can expect.

If I'm writing for an open source OS, that's probably some flavor of Linux. But which flavor? And which package manager does it use? And do they support all the dependencies I need, in the versions I need? Without pulling non-standard package repositories into the mix?

When open source software has difficulty working on proprietary OSes, I think it's usually not because of the package manager. More often it's because of something like a glibc dependency. At which point the domain of support isn't really "open source OSes", it's usually something more like "glibc-based linux distributions."

How is being free related to having a specific package in the package manager?

Why? Proprietary OS have package managers.

How so?

Because you can't guarantee that every distro's package manager will have the packages you need.

Build them from source, then.

Hare is a systems programming language. What kind of a systems programmer doesn't know how to build from source?

So the solution is just vendoring? Vendoring is very clunky—that's why we have package managers in the first place.

Language designers have every right to avoid complex features if such a feature impede the language in any way.

Hare does the smart thing - it decouples the library distribution model from the language.

After all, it's the programmers job to make sure that distribution and packaging of his/her library is as simple as possible.

Every programmer should not be re-solving the problem of library distribution just to distribute their library. This is a solved problem; a go-style git repository model is the bare minimum that a language should have.

Having to download several dependencies from random websiees and install them is not the most fun way to spend an afternoon. Especially if half of them have cryptic build errors.

So Github is a random website now?

I think that Hare's workflow and usecase encourages having very few or no dependencies.

That means, in most cases, you should just be able to download a project's source, build and use it right away.