|
|
|
|
|
|
by rendaw
23 days ago
|
|
|
Most of those deal with downloading large centralized indexes using git, not individual packages. > The problem was that go get needed to fetch each dependency’s source code just to read its go.mod file and resolve transitive dependencies. Cloning entire repositories to get a single file. Then it needs to compile the module, right? It's not downloading it twice. > Grab’s engineering team went from 18 minutes for go get to 12 seconds after deploying a module proxy. > ... > GOPROXY became the default in Go 1.13. The way this is written it sounds like go builds were extremely slow (18 minutes) so go adopted a proxy to speed things up. But Go 1.13 was released in 2020, and the blog post about 18 minutes is from 2023. There's no link to anything about GOPROXY. The vcpkg example also isn't a git issue, it sounds like just bad engineering from Microsoft. I'm willing to believe there are issues with using git, but that article is a letdown. |
|
|
It seems to imply the reasons were optimization and to protect from disappearing dependencies. It doesn't imply that there were any hidden dangers to git.
I think it's very possible that google simply thinks speed is more important than decentralization. And for google's purposes, a google-owned cache is probably a safe enough hedge against disappearing repos (read: if you're not google you'd need to evaluate this risk yourself).
Edit: Discussion from the time here: https://news.ycombinator.com/item?id=20837753 - in that thread too people don't really know why the proxy was needed (or like, "is it really just for speed? but it isn't particularly slow right now"). One additional reason is analytics collection.