3 ms·

This seems to only be a complaint about a particular (granted, default) proxy for downloading modules, and no criticism of the actual module system (which does

This seems to only be a complaint about a particular (granted, default) proxy for downloading modules, and no criticism of the actual module system (which does not depend on a proxy) nor the idea of a proxy (which is pretty easy to run, especially when compared to most other languages' package repositories). As to the criticism, if a public module isn't playing well with the default proxy, it's a good sign I don't want to use it to begin with.

yjftsjthsd-h 4y ago
> about a particular (granted, default) proxy Yeah, but defaults matter. That's one of Go's big selling points, usually. > As to the criticism, if a public module isn't playing well with the default proxy, it's a good sign I don't want to use it to begin with. The concern raised here is more that things only work because the proxy masks problems. Also alluded to is that said default proxy is kind of awful to its upstreams, unnecessarily pulling things and burning bandwidth.
- morelisp 4y ago
  > The concern raised here is more that things only work because the proxy masks problems. But making the modules available in the face of upstream breakage is a point of the proxy. I can still build when GitHub is down. I can still get the version of the source I expected when upstream rebases or retags. Those are reasonable defaults. And with one env var I can also turn that off and check that the upstream is still as I expect. > Also alluded to is that said default proxy is kind of awful to its upstreams This is debatable; sr.ht seems to want to host a lot of go repos but not have people pull a lot of go repos. I'm not sure that's a case worth catering too.