Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a first party hacky workaround

I agree. I've been using Go as my primary language since 2011. Its package management has always been fairly simple, but deficient. Go modules have made things more accessible, but it lacks serious features and actually has quite a few bugs and edge cases. Every time I use cargo I'm blown away, it's incredible. People often gloss over Go and lump it in with Rust which is giving it far too much credit.

I'm not saying it's great, but saying it was thought about even though one of go's design philosophies was to be as minimal as possible. That is, it's something that was thought of as part of the language development.

The same can't be said of slightly older languages like C#, Java, or python. Perl, for all its foibles, was probably the first language with a more modern package management system (CPAN).

I think its more like pretending that things are simple (or that a simple solution is enough), when in truth some things just aren't simple and pretending otherwise is unwise. Like how they ended up adding a package manager later on, which of course was never part of the initial design because they thought nobody needs to version their dependencies. Or how they ended up adding generics later on, because they thought nobody will ever need to do "abstract things".

The problem is if you don't consider these things in your initial design, the solution you end up with later tend to be worse.

Getting packages working in Go is approximately as low-friction as it is with any other language: "go get <whatever>". Packages are qualified by their Git repository URL, which addresses an important supply chain security issue (but creates other issues). Go has supported a thriving ecosystem of third party packages since approximately the moment it went mainstream.

So, ultimately, all people are saying when they knock Go's package management is that they don't like how it works. That's fine, I don't like how all sorts of things work. But "nothing" is false, and "hacky" is so subjective as to be practically worthless. Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language, and, to me at least, it follows obviously that they solves package management to some level of the community's satisfaction, because languages without package management aren't successful.

If we wanted to hash out the pros and cons of different package management strategies, that's all the thread will be: just hundreds of back-and-forth messages about package management. It's a big topic.

I think you're right that Go's current approach is similarly fine as the other ecosystems with basically fine approaches.

But they really did launch with no solution and take a fairly long time to figure it out.

>… Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language…

When I wrote Go, the official language policy is that you do not need versioning and should not make breaking changes. Throw everything into a vendor/ if you must. For me, that kind of stance on package management definitely warrants attention.

People have all sorts of thresholds past which attributes of package management warrant attention. Some of them are even reasonable. But it's not legitimate to claim that a language doesn't have any effective package management, at least when that language is (a) popular and (b) idiomatically dependent on 3rd party packages, simply because those thresholds get crossed. Go self-evidently has effective package management, and has for over a decade.

There are lots of things I don't like about NPM. But imagine claiming that Node doesn't have real package management. You can't even write a for-loop in Node without a package. Go isn't quite that far gone, but it's pretty hard to write idiomatic Go of any significance with zero packages.

I'm not sure when you wrote go, but versioning is even more clearly part of the package management than with other languages. Major versions of a library have different import paths, such that you can look at the top of any file and know exactly which major version of a dependency it's using.

Is it even fair to call them packages? It’s a slightly more convenient method of repo sub modules, but there isn’t any object reuse or sharing outside of a workspace.

Would you say that that's a good thing? I'm so tired of trying to figure out which package manager is responsible for which thing and keep track of their various idiosyncrasies.

I think nix might be the way--just have one package manager to rule them all--but I'm not aware of any language ecosystems that are leaning into this.

> Would you say that that's a good thing?

Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee.

> but I'm not aware of any language ecosystems that are leaning into this.

Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages.

For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.

> the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20.

To be fair, Haskell doesn't have 20. It has two.

Just a sec, let me go create 18 more ;)

But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.

Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world.

It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different.

They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them.

Learning languanges would be so much fun if I didn't have to learn a new package manager each time.

The important thing that happened for Java is the centralized repository. Gradle and maven both use the maven repository standard. So you can publish a new package and either system can pull it in. This isn't as true if you talk about plugins to the build systems so it's not as if java is unscathed.

However, I'd say it's a lot better situation than what exists for C/C++ ATM.

I'll agree that having strong consensus about the map:

(Package name, version number) -> (cryptographic hash of package bits)

Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems.

I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time.

I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies.

Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.