I just want to agree with one of the commenters, that
go getignoring versioning is also a massive pain with the language. The official justification is that the Go developers did not know what the community would want, so they “didn’t build anything.”
But they did, and it’s called
go get… and they were right, it is not what anyone wants.
Unfortunately, since it’s also the only thing included by default—as well as being a great party trick, “just include this package and
go getknows how to find it”—people will try to use it, and it will burn them.
We can express that a repository has code compatible with Go 1.0 by giving it a
go1branch, but there’s nothing to indicate any higher minor versions. Libraries wanting to be friendly to
go getmust be written to Go 1.0 for ever and ever, no matter how much the language improves afterward.
After this was painfully apparent, the official story switched to “vendor all your dependencies.” As in, use some extra tool to get a copy in your project and completely ignore
$GOPATH. Worse, it wasn’t just “some” extra tool, but there was a page with number of vendoring tools that worked in different ways with different feature sets. You were expected to “pick one” that suited you.
Then they decided that was all wrong, and that vendoring would be understood by the language itself, someday. Which will be great, once that version makes it everywhere, and the feature can be relied upon. We might be waiting a long time for it to land in RHEL and Debian stable.
I’m happy they’re fixing it, eventually. I really am. This is a major complaint, and they’re getting rid of it.
Now if only they could do the same for generics. It’s really frustrating having a first-class function that has no-class data.
Post a Comment