So instead of creating M packages * N OSes, we do it just once.
No, creating M packages x N OSes is exactly what we do. In fact, we create M+N package-managers x N OSes - and then also create MxN packages.
If you can write a language-specific package manager for all OSes, you can also write a non-language-specific package manager for all OSes, so I the "it doesn't work in all distributions" argument is just a symptom of my complaint. Instead of working towards a cooperative packaging solution where the effort of packaging can be re-used, we continue to create more and more special snowflakes and fragmentation.
My C++, Java and .NET packages work everywhere there is a toolchain available.
Can you explain why that would be a problem? It's certainly not a technical one, none of these are special when it comes to versioning or dependency management of software. I can see that there's a social/political problem - which is exactly what I'm talking about.
A package format that supports all OS system paths, installation processes, difference between build time/dev time/deployment time, language compilation toolchains, compiler flags, ways to address hardware resources,OS specific deployment processes, ... is bound to the lowest common denominator for any chance of success.
Thus forcing everyone that needs something beyond that lowest common denominator to implement their own workarounds, thus we are again back to language package managers.
ISTM the "lowest common denominator" is a superset of everything current language-specific package-managers support and a subset of anything a current language-agnostic package-manager supports (pretty much definitionally). So ISTM that this is a net win - easier to build than APT/DNF/Pacman… and yet more useful than npm/stack/pip/…
In particular, I don't know any currently existing language-specific package-manager that supports what I'd call the GCD of package-management (e.g. none that I can think of supports actual OS-specific installation of packages) so that clearly isn't even a requirement.
> Thus forcing everyone that needs something beyond that lowest common denominator to implement their own workarounds, thus we are again back to language package managers.
FWIW, a) part of the political and social problem is to talk more honestly about what "needing" really means and b) no, that's not at all "back to language package managers". You can have a layered design, e.g. splitting the "building" and the "installation" part, thus letting languages implement their workarounds in their dedicated building layer and letting OSes implement their workarounds in their installation layers. You just need to actually sit down and talk about the interface needed between the two (and the sets of layers actually needed, which will be >2). Which no one seems really willing to do.
For non-go tools like the protoc compiler I don't think the golang tooling provides any help. A heavyweight option would be a build system like bazel
- https://github.com/golang/tools/blob/master/cmd/golsp/main.g...
I am glad to see that the go team is working on cleaning up the tooling situation. I used gocode, then started using modules, found that the primary version was unmaintained, and had to switch to a different fork. I believe I also needed a different version of goimports for a while. Having all this tooling unified into the langserver maintained alongside go sounds wonderful. I hope other languages do the same thing.