I find them very refreshing compared to other dep mgmt systems. They also have a lot of secondary benefits most are not aware of.
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
It's definitely more convenient than Python's venv dance.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
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.