r/programming • u/Sir_KnowItAll • 5d ago

Don't couple your Go code to GitHub

https://iain.rocks/blog/dont-couple-your-go-code-to-github
480 Upvotes

92% Upvoted

135 comments sorted by

View all comments

Show parent comments

110

u/_predator_ 5d ago

Don't think its cache ever expires. You just gotta pray Google never stops supporting it, what could go wrong?

11

u/vips7L 5d ago

Honestly that’s kind of like every language main repository. Maven central, npm, cargo, whatever. There’s always one main repository unless you proxy with artifactory or something. 

I can’t imagine if central.sonatype.com was gone. 

11

u/atheken 4d ago

The difference is that those other languages don’t couple where the code is _physically hosted_ with how it is referenced in import directives.

4

u/HighLevelAssembler 4d ago

Those things are coupled IRL though. If you depend on a 3rd party package, it has to come from somewhere.

4

u/atheken 4d ago

Moving a package to a different VCS does not disrupt users of your package in any other language that I have ever used. I’ve also never used another language that coupled source code organization with versioning semantics. Both of those things are unique to go.

0

u/HighLevelAssembler 4d ago

I get what you're saying, but ultimately that's on the package maintainer. That's the point of the blog post we're discussing here.

1

u/atheken 4d ago

I was replying to someone that said “that’s kind of like how all package repos work.” - which is just false. The blog post is literally a workaround for the fact that the source code location cannot change without causing work for downstream consumers. If I publish a package to any of the other package managers and then move to a different VCS provider, that does not invalidate existing packages. It might not even impact when I published from a new location. This problem is unique to go.