I wish they would ask what makes it difficult to work with dependencies in Go.
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.
The general model for package management in other language ecosystems is rubygems and bundler.
Like: a GitHub founder invented semantic versioning.
I find them very refreshing compared to other dep mgmt systems. They also have a lot of secondary benefits most are not aware of.
go mod init <name>
[write code]
go mod tidy
go build
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.
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.
echo 'package main
import "fmt"
func main() { fmt.Println("hello"); }
' > foo.go && go run foo.go