3 ms·

I disagree with all of this. Go's package management system is a breath of fresh air compared to all other languages. Nobody ever has any problem grabbing dep

I disagree with all of this. Go's package management system is a breath of fresh air compared to all other languages. Nobody ever has any problem grabbing dependencies. There is only one way to do it and it's built into the language runtime; if you have Go installed you can install the modules. Other applications on your system can, with no effort (virtualenv, etc.) use different versions of those modules. Dependency installation can't print messages to my terminal. It's a joy. Importing modules from a particular URL is a great way to handle them. No central server required! Everyone can name their module "utility utils" or whatever. And, nobody is forcing you to use Github to host your modules, you can put them on any web server you control and import them as example.com/your-thing. Decentralized. Easy to use. If I had two complaints, they would be: 1) Library authors that think "replace" directives propagate up to consumers. They do not. They are ignored when you depend on the module. If you depend on one of these libraries and want the workaround that the author has smoothed over with a "replace" directive, you have to copy that directive to your own go.mod. 2) Library authors that distribute one go module for their super-complicated server and their super-simple client. This results in unnecessary dependency explosion. (Loki 1.x was an example of this pattern. Their server depends on things like Kubernetes, where their client only depends on net/http. But if you naively import their client, suddenly your project depends on Kubernetes.) (2a would be no concept of test-only modules. Some modules are only needed for the tests; it would be nice to not propagate these up to consumers. It isn't an actual problem, though, just a "would be kind of nice" or "I could see why they did that" if it existed.) Neither of these are Go issues, just maintainer issues that can happen with any language.

Macha 5y ago
If you use your own server you're now obligated to keep it up forever or break all your users. If you use a hosted service like github, you might still find it breaks when you do something like change the case on your username.
- jrockway 5y ago
  The module proxy should smooth over any random downtime. (See https://proxy.golang.org/ https://proxy.golang.org/) Everything on the Internet is vulnerable to this. NPM has gone down. You can send NPM a legal request to delete a module. Your domain registrar can take your domain name. Your local IP address registry can take away your IP address. At the end of the day, you can vendor all your modules and keep them with your source code if this worries you. It's not really in scope for a programming language to make a completely immutable and takedown-proof Internet just to let Internet users share some code with each other. But, they've done a pretty good job here.
6figurelenins 5y ago
> There is only one way to [grab dependencies] and it's built into the language runtime The `go` tool. "Language runtime" refers to the ~2MB of thread scheduler, garbage collector, etc. > No central server required! Now you have five proxies to choose from, because coupling your project to a bunch of strangers' version control systems is bananas. > Neither of these are Go issues, just maintainer issues In practice, separating downstream quality-of-life from the language proper seems to breed chaos. Example: https://github.com/golang/go/issues/24661 https://github.com/golang/go/issues/24661 Until I have an extremely Go-shaped problem, I don't need that headache.
_tom_ 5y ago
I do not program in Go. Every non-tiny place I have worked finds it necessary to copy known working versions of code they rely on, to an internal server and build from there. You don't have reproducible builds, for example, from a remote sever (maybe there are hashes?). But even then you don't have reliable access to external servers (they may crash, be bought, be hacked, change business models). So people self-host what they use. Can you do this in Go, without changing source code? ======================================================== Not related to above, your 2) reminds me of my pet peeve: doc dependencies included in module dependencies. Oh, you use Sphinx, we'll install that. Oh, Sphinx needs Python, we'll install that. Try to use a simple, non-Python, library, get Python and all it's dependencies. Dependency explosion is a real, really bad thing.
- klabb3 5y ago
  > Can you do this in Go, without changing source code? Yeah, IIUYC it even has first class support: `go mod vendor`

Macha 5y ago

If you use your own server you're now obligated to keep it up forever or break all your users. If you use a hosted service like github, you might still find it breaks when you do something like change the case on your username.

jrockway 5y ago
The module proxy should smooth over any random downtime. (See https://proxy.golang.org/ https://proxy.golang.org/) Everything on the Internet is vulnerable to this. NPM has gone down. You can send NPM a legal request to delete a module. Your domain registrar can take your domain name. Your local IP address registry can take away your IP address. At the end of the day, you can vendor all your modules and keep them with your source code if this worries you. It's not really in scope for a programming language to make a completely immutable and takedown-proof Internet just to let Internet users share some code with each other. But, they've done a pretty good job here.

6figurelenins 5y ago

> There is only one way to [grab dependencies] and it's built into the language runtime The `go` tool. "Language runtime" refers to the ~2MB of thread scheduler, garbage collector, etc. > No central server required! Now you have five proxies to choose from, because coupling your project to a bunch of strangers' version control systems is bananas. > Neither of these are Go issues, just maintainer issues In practice, separating downstream quality-of-life from the language proper seems to breed chaos. Example: https://github.com/golang/go/issues/24661 https://github.com/golang/go/issues/24661 Until I have an extremely Go-shaped problem, I don't need that headache.

_tom_ 5y ago

I do not program in Go. Every non-tiny place I have worked finds it necessary to copy known working versions of code they rely on, to an internal server and build from there. You don't have reproducible builds, for example, from a remote sever (maybe there are hashes?). But even then you don't have reliable access to external servers (they may crash, be bought, be hacked, change business models). So people self-host what they use. Can you do this in Go, without changing source code? ======================================================== Not related to above, your 2) reminds me of my pet peeve: doc dependencies included in module dependencies. Oh, you use Sphinx, we'll install that. Oh, Sphinx needs Python, we'll install that. Try to use a simple, non-Python, library, get Python and all it's dependencies. Dependency explosion is a real, really bad thing.

klabb3 5y ago
> Can you do this in Go, without changing source code? Yeah, IIUYC it even has first class support: `go mod vendor`