Hacker News Reader

Comment by sophacles | Hacker News Reader

I have yet to come across a go project that doesn't pull in tons of 3rd party code as well. It seems like maybe you're over-stating the "culture" a bit.

View on HN

> I have yet to come across a go project that doesn't pull in tons of 3rd party code as well.

These have Zero dependencies. It's not rare in Go land.

- https://github.com/go-chi/chi 19k stars

- https://github.com/julienschmidt/httprouter 16k stars

- https://github.com/gorilla/mux 21k stars

- https://github.com/spf13/pflag 2.6k stars

- https://github.com/google/uuid 5.6k starts

Many others have just a few dependencies.

Yeah, while I’ve seen some great libraries that follow the practice of minimizing their dependencies, I’m a bit annoyed with the amount of dependencies that docker will bring along [1]. I’ve been on the lookout for alternatives for my docker needs, but the state of podman, buildah and some others that I checked is similar. They all bring in roughly the same number of dependencies… if anyone knows of a stripped down Go lib that can be used to build from a Dockerfile, pull, and run a container, I would be grateful for any suggestions. Heck docker / moby isn’t even using go.mod proper.

[1] https://github.com/moby/moby/blob/master/vendor.mod

Wow, that's massive. I guess it's inevitable that a popular piece of open-source software for end-users will be compelled to accrue dependencies due to popular demand for features that require them.

I feel Telegraf made a good compromise: out of the box, it comes with a _ton_ of stuff[1] to monitor everything, but they make it possible to build only with pieces that you need via build tags, and even provide a tool to extract said tags from your telegraf config[2]. But lots of supply-chain security stuff assume everything in go.mod is used, so that can results in a lot of noise.

[1] https://github.com/influxdata/telegraf/blob/master/go.mod [2] https://github.com/influxdata/telegraf/tree/master/tools/cus...

Thanks! That’s an interesting approach. Haven’t seen that before. I think a better approach (in a monorepo) might be to use separate go.mod files for each module, allowing the user to configure only the needed parts separately. But I haven’t seen it used much.

Reply on news.ycombinator.com