Hacker News Reader

Comment by jmyeet | Hacker News Reader

I like Go but Go has made some serious misteps (IMHO), which the author touches on. Dependency management in Go is so incredibly bad it's hard to fathom. Did no one on the early design team ever deal with depenencies? Java is so much better here and came years earlier. Go would've been so much better had they just copied any of the Java options from Day One.

So this versioning thing is just weird and I agree with the author. It's a strange thing to have opinions on and an even stranger opinion to have on that thing.

But the thing that gets me is the whole putting "github.com/username/module" into code is just awful.

View on HN

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.

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.

The module proxy should smooth over any random downtime. (See 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.

> 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

Until I have an extremely Go-shaped problem, I don't need that headache.

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.

> Can you do this in Go, without changing source code?

Yeah, IIUYC it even has first class support: `go mod vendor`

I absolutely disagree with everything said here.

Maven naming convention is absolutely atrocious. And don't tell me that naming convention is optional. To be part of Java ecosystem Maven naming convention is a requirement.

This comment is empty of content. All you've said is "go is bad" over and over again. Who would be persuaded by this?

> Dependency management in Go is so incredibly bad it's hard to fathom.

It used to be pretty terrible. Today it's at least as good as npm.

> Did no one on the early design team ever deal with depenencies?

It was developed at Google and they have a giant monorepo, associated infrastructure, as well as company policies against multiple versions of dependencies. They also vendor external deps into this repo. So no, Google deals with dependencies a lot, but they do things very, very differently from almost everyone else.

sorry is github.com/username/module is much worse than

com.arbitrary.x.y.z ?

In the source file one could just say

    import “username/module”

And in the go.mod file the whole URL can stay

    require github.com/username/module v1.2.3

I only see advantages with this approach and I imagine it’s a rather “easy to add” feature that can be even backwards compatible.

What if I publish gitlab.com/username/module and i dont know anything about your github project? This seems like a pretty obvious disadvantage, so its surprising you failed to see it. What are the advantages?

Shamelessly pasting my reply to parent:

> Conflict resolution within the same module could be handled in the go.mod file:

> `require alias github.com/...`

I would take this further, simply `import "module"` would be nicer. (I don't care about anyone's github username, and I often need to fork projects and today that means mindless search and replace)

Conflict resolution within the same module could be handled in the go.mod file:

`require alias github.com/...`

Reply on news.ycombinator.com