3 ms·

I think it's a "cultural" thing. With Go you often find developers/projects proudly mentioning that any or just a few non-std dependencies are used. Coming from

by XxiXx 1y ago

I think it's a "cultural" thing. With Go you often find developers/projects proudly mentioning that any or just a few non-std dependencies are used. Coming from Go it really feels strange when you see pages of dependencies scrolling over your screen when you build a Rust project.

deleted 1y ago
[deleted]
sophacles 1y ago
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.
- meling 1y ago
  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 https://github.com/moby/moby/blob/master/vendor.mod
  - lantastic 1y ago
    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 https://github.com/influxdata/telegraf/blob/master/go.mod [2] https://github.com/influxdata/telegraf/tree/master/tools/custom_builder https://github.com/influxdata/telegraf/tree/master/tools/cus...
    - meling 1y ago
      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.
- hu3 1y ago
  > 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 https://github.com/go-chi/chi 19k stars - https://github.com/julienschmidt/httprouter https://github.com/julienschmidt/httprouter 16k stars - https://github.com/gorilla/mux https://github.com/gorilla/mux 21k stars - https://github.com/spf13/pflag https://github.com/spf13/pflag 2.6k stars - https://github.com/google/uuid https://github.com/google/uuid 5.6k starts Many others have just a few dependencies.
api 1y ago
Go has a fatter standard library and a "fat" runtime with built-in green threads (an asynchronous runtime basically) and garbage collection, so you get more out of the box and thus end up using fewer dependencies.

by XxiXx 1y ago

deleted 1y ago

[deleted]

sophacles 1y ago

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.

meling 1y ago
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 https://github.com/moby/moby/blob/master/vendor.mod
- lantastic 1y ago
  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 https://github.com/influxdata/telegraf/blob/master/go.mod [2] https://github.com/influxdata/telegraf/tree/master/tools/custom_builder https://github.com/influxdata/telegraf/tree/master/tools/cus...
  - meling 1y ago
    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.
hu3 1y ago
> 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 https://github.com/go-chi/chi 19k stars - https://github.com/julienschmidt/httprouter https://github.com/julienschmidt/httprouter 16k stars - https://github.com/gorilla/mux https://github.com/gorilla/mux 21k stars - https://github.com/spf13/pflag https://github.com/spf13/pflag 2.6k stars - https://github.com/google/uuid https://github.com/google/uuid 5.6k starts Many others have just a few dependencies.

api 1y ago

Go has a fatter standard library and a "fat" runtime with built-in green threads (an asynchronous runtime basically) and garbage collection, so you get more out of the box and thus end up using fewer dependencies.