Hacker News Reader

Comment by jrockway | Hacker News Reader

Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with "npx"; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn't compile.)

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.

View on HN

This is exactly why I personally think efforts for language-specific package management in general are misguided. This is a solved problem in general-purpose package-managers (apt, dnf, pacman,…), for all their flaws. I don't understand why we need to re-invent that over and over again, including all the duplication of effort to re-package everything over and over again…

Because a language-specific package management work in all OSes supported by the language, while OS specific packages work in a single distribution, or not all in OSes that don't offer such support.

So instead of creating M packages * N OSes, we do it just once.

> 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.

Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for.

My C++, Java and .NET packages work everywhere there is a toolchain available.

> Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for.

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.

It surely is a technical one above any political willingness.

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.

> is bound to the lowest common denominator for any chance of success.

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 tools in golang like goimports the best practice at the moment is to have a tools.go with a "tools" build tag. See https://github.com/golang/go/issues/25922

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

On a vaguely related note, is there any decent documentation for writing a lang server. I've seen the official documentation by Microsoft and while it does seem a detailed reference, it's not great for someone who doesn't even know where to start in writing one.

this is being worked on:

- https://github.com/golang/tools/blob/master/cmd/golsp/main.g...

I don’t want to create one for Go. It’s for a hobby language I’ve created.

I only mentioned it because the op discussed Go’s language server.

Reply on news.ycombinator.com