On the world of DLLs and COM, those compile times are relatively ok.
k8s has so far decided not to use module versions, which makes using k8s with Go hard.
Unless by then cargo has already learned how to deal with binary crates.
I agree that Cargo is much better than the Go build system, though.
Binary caching á la Nix can work, but I can't really see that working out without Nix's commitment to environment purity.
Sounds like something is pretty screwed up if you're running cargo clean as part of your regular workflow.
> works in domains that don't depend on selling binary libraries for their business
Play stupid games, win stupid prizes? Meh.
Rust Cargo does about as well, probably the best for a compiled language. NPM could be about as good too - it almost feels like they deserve a point off for the ridiculously huge number of tiny packages required to do anything, though that isn't really the dependency manager's fault.
If you want to be sure of what version you get, use it.
Yes, you can ask the tool to print them. This is way worse than any of the other systems being discussed, where you can read a file in the repo.
So other than having a lockfile and having a flexible version specification (and a sensible way to resolve multiple version requests), Maven did "it" first!
... what was "it" again?
$ /usr/bin/time go build ./cmd/ekglue
70.33user 32.72system 0:07.92elapsed 1300%CPU (0avgtext+0avgdata
583644maxresident)k
333392inputs+1232496outputs (14768major+1135114minor)pagefaults 0swaps
$ /usr/bin/time go build ./cmd/ekglue
1.54user 0.90system 0:00.33elapsed 741%CPU (0avgtext+0avgdata
71952maxresident)k
16inputs+0outputs (3major+11111minor)pagefaults 0swaps
As for modules, I like them. My biggest blocker in using other programming languages is that their package system sucks compared to Go. I do run into problems -- upstream authors don't really know how to use Go modules, and upstream applications are very quick to take on unnecessary dependencies. For example, I depend on the Loki client. The Loki client and server are the same Go module, so they pin me to a particular version of the Prometheus library (that the Loki server depends on), which then pins me to a particular version of the Kubernetes library (that Prometheus depends on). Basically, the dependency graph is hundreds of times larger than it needs to be, because it's not a problem for the upstream authors and they've never thought about it. Splitting the client and server into two modules would make life much easier for consumers, but slightly harder for the producer, so it's rare that you see it one. (My team also makes an app that makes this same mistake -- forcing users of the client to depend on things like Kubernetes. It's hard to fix, because the server uses the client internally, but I may do it in the future. Or just auto-copy the client code into a separate repo + go.mod file for consumers!)
Upstream authors are also very quick to make fixes for themselves, unaware that they don't propagate to consumers. Many libraries have "replace" directives in go.mod, but those don't propagate to consumers, causing solved problems to reoccur for each consumer. You have to manually propagate them yourself. The solution there is to be a good open-source citizen -- if you have to hack up some module, either properly fork it and depend on the fork (there should be a tool that handles this renaming for you automatically), or push your changes upstream and depend on the new release.
Basically, modules involve the transitive closure of all shortcuts a bunch of people you've never met have taken, and the results are not always good. That has been true in every language I've ever used; I have 83 irrelevant Depndabot alerts that can't be fixed in most of my Javascript projects, for example. I think it's the best module / packaging system I've ever used, and I like it very much. In fact, there is little I'd change.
> figure out what versions are actually being built into the final binary
go list -m all
go list -m -u all
I personally include this in every binary I produce: https://github.com/povilasv/prommod
This lets me monitor module versions across the fleet. If there's a security problem in a module, I can instantly see which apps are affected, and update them.
minor correction: just `go list` on these. the `-m` ensures it's in module-mode.
Its slightly annoying that your dependencies' optional dependencies pollute your go.sum, but it really doesn't matter. If those don't show up in your package import graph they won't be included in your builds.
I made a test module that depends on loki and kubernetes, and updating kubernetes results in:
$ go get k8s.io/[email protected]
go: downloading k8s.io/client-go v0.19.0
go get: downgraded github.com/grafana/loki v1.5.0 => v1.0.2
go get: downgraded github.com/thanos-io/thanos v0.12.1-0.20200416112106-b391ca115ed8 => v0.11.0
go get: downgraded k8s.io/client-go v12.0.0+incompatible => v0.19.0
I don't blame the module system for this, I think it's doing a great job. But when you use other people's code, you're responsible for the transitive closure of all their minor tiny mistakes, and when you depend on big codebases, the mistakes really add up. That's where the hate comes from; a lot of code was written before modules existed, and modules changed the semantics of that code.
Your Go project must be on an epic scale to break even 10 minutes of compile time.
Obligatory XKCD: https://xkcd.com/303/