With Go being a new language (1.0 in 2012), there is no excuse for not having had a solid pkg solution in 1.0.
It's one of the things holding Go back, in my opinion, producing makeshift solutions like Glide and gopkg.in, which are only minimally adopted.
I hope they also specify some mandatory versioning scheme (like npm with semver), because there are so many Go packages out there which don't even do any versioning!
There's no reason you can't use the same package format and tools for code written in multiple languages. You might get some additional convenience by having small language-specific plugins (like the automatic dependency extractors in RPM) but that's just a tiny amount of the necessary tooling. The vast majority is not language-specific at all.
With these language-community systems, there's also the problem of depending on code written in another language. My Go program might well depend on a C library, just as my C program can require a shell script.
Generally languages need a good tool to allow (nested) dependencies that has a simple (preferably declarative) dependency file.
Would it be nice to be able to have a cross language platform tool(jvm tools do generally play nice across languages in my understanding) like nix that also allows setting up other non language specific dependencies? Yes. But I'm not sure any are good enough/simple enough yet. Also language ecosystems tend to avoid non language dependencies (unless they're so common theyre typically installed with the language like lxml/libxml2) or have crappy ways to try to build c dependencies. So this is if not solved partially worked around.
These package managers are mostly for development, not deployment although frequently they are also used to build or even deploy code.
It would be nice for each language package manager to have plugins to generate self contained deb/rpm/ect. for deployment or even fancier to allow some dependencies to be (assuming it's not a language that prefers static linking/bundling) satisfied by system packages. But these take time and effort to write.
The Golang ecosystem is in an incredibly weak state when you compare it with other modern languages.
Major issues:
-)
Due to the lack of a proper package system, there's also no central pkg repository, which really hurts discoverabilty and growth of the ecosystem a lot. Just compare it to solutions like NPM for node, https://crates.io for Rust, Hackage for Haskell, etc...
Github + https://godoc.org/ is not a replacement for a proper package repository.
-)
Like I mentioned, way, way too many Go packages don't follow a proper release process with versioning and release notes. AT ALL. You often need to mirror repos for your own project, and closely track what upstream projects are doing. git clone + go get for your big projects just doesn't work.
This is incredibly problematic when developing big projects. A proper pkg solution should enforce versioning and release best practices.
Just the docs for the tip of master are far from what people expect.
"Serving 28 versions of 12 nuts published by 80 registered users."
There's just very little adoption for these, and there won't be unless it's official.
It seems to me that while I'm on the GitHub page anyway, it's reasonably convenient to just copy-paste the URL in a file so I can pull in the package and use it. I can't imagine just using a package repo for discovering new packages, that would be tantamount to just pulling whatever random code someone wrote that looks like it might solve my problem.