4 ms·

I wish they would ask what makes it difficult to work with dependencies in Go.

by mfer 4y ago

verdverm 4y ago
What is difficult? I find them very refreshing compared to other dep mgmt systems. They also have a lot of secondary benefits most are not aware of. https://verdverm.com/go-mods https://verdverm.com/go-mods
- bragr 4y ago
  I find go's package system both too cumbersome for small/quick projects, and yet leaving me wanting in more complex scenarios. It's gotten better of the years, but I never really enjoy my encounters with go-mods
  - bheadmaster 4y ago
    I find go's package system very convenient for quick projects: go mod init <name> [write code] go mod tidy go build It's definitely more convenient than Python's venv dance.
    - just-ok 4y ago
      Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. I usually resort to the Go playground for them.
      - bheadmaster 4y ago
        > Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. True. Though installing third-party dependencies globally is considered bad practice, since it can easily break system packages. > The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. Well, if you just want to compile/run a single file (or a couple of files) without third-party dependencies, `go build main.go` and `go run main.go` will work just fine, too.
        BobbyJo 4y ago
        I can't tell you how many time global dependencies in python have cause me headaches. Do a small project then do another small project 6 months later and the formers dependencies conflict with the latter's.
        bheadmaster 4y ago
        The whole concept of "only one major version of library can be installed at a time" is completely broken and is the direct cause of diamond import issues. Go designers have correctly recognized that two major versions of a library are actually two different libraries, only under the same name and the same team. The "v2/ subdirectory" practice of versioning Go packages is one of the things I love the most about Go. Combined with the "packages are directories" philosophy, it makes it easy to use as many major versions of the library as you want, without any complications whatsoever.
        klooney 4y ago
        It's such a nightmare for internal scripts. Even for ruby shops where theoretically bundler solves the problem there's all these cowboys with ten external dependencies and no lockfile
      - biztos 4y ago
        I use Go and Python both for short scripts and tests in a very similar way, when the Standard Library covers my needs. echo 'package main import "fmt" func main() { fmt.Println("hello"); } ' > foo.go && go run foo.go But once I have to worry about dependencies, I do prefer Go's "pretend you are a module" dance vs. Python's "discover the differences between your install and the author's install" dance.
  - Thaxll 4y ago
    Go mod is one of the best package manager out there, to work daily you need 5-6 commands that it's and it's very fast.
numbsafari 4y ago
I agree with the sibling: go dependencies generally work exactly they way I want them to, and I find it very refreshing relative to other ecosystems. My guess is that folks coming from those other ecosystems are frustrated that it doesn't work exactly like NPM, which is the general model other ecosystems have decided to follow, despite it being unstable and insecure by design. Internally, we use a build tool called Please that is very similar to Bazel. We have some internal tooling to automate the generation of third-party dependency boilerplate needed by the build tool. The go dependency tooling actually made this reasonably straightforward and super efficient to accomplish relative to other dependency managemers. If you are in a setup where you aren't working with multiple languages or complex builds, and can just use the raw go tooling to build... the story is even easier. Would be interesting to hear of specific pain points that others face.
- 6figurelenins 4y ago
  > My guess is that folks coming from those other ecosystems are frustrated that it doesn't work exactly like NPM, which is the general model other ecosystems have decided to follow The general model for package management in other language ecosystems is rubygems and bundler. Like: a GitHub founder invented semantic versioning.

I wish they would ask what makes it difficult to work with dependencies in Go.

by mfer 4y ago

I wish they would ask what makes it difficult to work with dependencies in Go.

What is difficult? I find them very refreshing compared to other dep mgmt systems. They also have a lot of secondary benefits most are not aware of. https://verdverm.com/go-mods https://verdverm.com/go-mods

bragr 4y ago
I find go's package system both too cumbersome for small/quick projects, and yet leaving me wanting in more complex scenarios. It's gotten better of the years, but I never really enjoy my encounters with go-mods
- bheadmaster 4y ago
  I find go's package system very convenient for quick projects: go mod init <name> [write code] go mod tidy go build It's definitely more convenient than Python's venv dance.
  - just-ok 4y ago
    Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. I usually resort to the Go playground for them.
    - bheadmaster 4y ago
      > Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. True. Though installing third-party dependencies globally is considered bad practice, since it can easily break system packages. > The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. Well, if you just want to compile/run a single file (or a couple of files) without third-party dependencies, `go build main.go` and `go run main.go` will work just fine, too.
      - BobbyJo 4y ago
        I can't tell you how many time global dependencies in python have cause me headaches. Do a small project then do another small project 6 months later and the formers dependencies conflict with the latter's.
        bheadmaster 4y ago
        The whole concept of "only one major version of library can be installed at a time" is completely broken and is the direct cause of diamond import issues. Go designers have correctly recognized that two major versions of a library are actually two different libraries, only under the same name and the same team. The "v2/ subdirectory" practice of versioning Go packages is one of the things I love the most about Go. Combined with the "packages are directories" philosophy, it makes it easy to use as many major versions of the library as you want, without any complications whatsoever.
        klooney 4y ago
        It's such a nightmare for internal scripts. Even for ruby shops where theoretically bundler solves the problem there's all these cowboys with ten external dependencies and no lockfile
    - biztos 4y ago
      I use Go and Python both for short scripts and tests in a very similar way, when the Standard Library covers my needs. echo 'package main import "fmt" func main() { fmt.Println("hello"); } ' > foo.go && go run foo.go But once I have to worry about dependencies, I do prefer Go's "pretend you are a module" dance vs. Python's "discover the differences between your install and the author's install" dance.
- Thaxll 4y ago
  Go mod is one of the best package manager out there, to work daily you need 5-6 commands that it's and it's very fast.

numbsafari 4y ago

I agree with the sibling: go dependencies generally work exactly they way I want them to, and I find it very refreshing relative to other ecosystems. My guess is that folks coming from those other ecosystems are frustrated that it doesn't work exactly like NPM, which is the general model other ecosystems have decided to follow, despite it being unstable and insecure by design. Internally, we use a build tool called Please that is very similar to Bazel. We have some internal tooling to automate the generation of third-party dependency boilerplate needed by the build tool. The go dependency tooling actually made this reasonably straightforward and super efficient to accomplish relative to other dependency managemers. If you are in a setup where you aren't working with multiple languages or complex builds, and can just use the raw go tooling to build... the story is even easier. Would be interesting to hear of specific pain points that others face.

6figurelenins 4y ago
> My guess is that folks coming from those other ecosystems are frustrated that it doesn't work exactly like NPM, which is the general model other ecosystems have decided to follow The general model for package management in other language ecosystems is rubygems and bundler. Like: a GitHub founder invented semantic versioning.