Hacker News Reader

Comment by kardianos | Hacker News Reader

In the go ecosystem, packages are imported per file. Go is designed for large systems to evolve over time. You need to be able to refer to v1 and v2 at the same time.

Thus the "/v2" requirement.

Yes, it is different. Stop complaining, do it, and it just works. Here is the tutorial.

1. Modify go.mod package path to include the "/v2" element. 2. Commit. 3. Tag as "v2.0.0" 4. Push tag.

I'm not seeing what is too confusing about releasing.

To consume, on packages that you want it, import the new package. Done.

Being able to import multiple versions without conflict has been extremely helpful when I've needed new features in one version, but didn't want to update (at the same time time) all the other places.

I really don't get why people don't like it, other then it is different then what they expect elsewhere.

View on HN

It works fine to the degree that the module is stateless and is designed to be used as a library, functionally scoped.

To the degree that a module is stateful, designed to be used as a framework, and have long-term persistence, it doesn't.

OK for calculations; less than OK for a network server or data store.

It's actually pretty much the only consistent and guaranteed backwards compatible way to deal with such changes.

There's no guarantee of backwards compatibility without limiting of forward functionality. The trade-off can't be escaped.

If you can make do without any persistent state, or global or externally visible resources (network connections, configuration files, etc.), then you're OK. But that's a limitation.

Modules that rely on global state for anything other than memory pooling or what have you should be avoided. It’s a lot more testable and clean to return a high level data structure that contains any of that state you would have held before globally in the module and have that be the “context” or just the parent data structure to any others that are spawned.

Global state makes thing impossible like parallel unit tests that all use another module, or changing things like “MaxConcurrency” in a way that is synchronized across goroutines that might already be calling into the third party module.

My 2c.

Of course. I'm not advocating global state. It's just that most real systems have things like file systems, config files, databases, listening network sockets, etc. These are inherently non-local.

As I pointed out elsewhere in this thread, I think this is an inaccurate statement, as somehow numerous other mainstream languages have had ecosystems with libraries that provide backwards-compatibility, because they have real package management systems that allow you to target specific module versions.

> Go is designed for large systems to evolve over time

If this was the goal, it was certainly not make clear in any prominent places and occasions.

Speaking from experience working on large golang projects, it's just a baseless claim repeated by people over and over. In practice, golang is worse than languages and systems like Java and C#.

> Yes, it is different. Stop complaining, do it, and it just works. Here is the tutorial.

Right. And all tis is described in accessible form where exactly?

Also, here's the very helpful error that go spits at you: https://news.ycombinator.com/item?id=24432511

Its been covered in detail here: https://blog.golang.org/using-go-modules

I will quote the article were commenting on:

> For what it's worth, the official Go Blog tried to clear the situation up some, and posted a write-up about it.

> blog.golang.org/v2-go-modules

> Even as a seasoned developer, I found this write-up somewhat impenetrable. For how important and unusual of a requirement this is, the write-up is not accessible enough.

Somewhere in the comments someone mentioned that "the actual info" on modules is here: https://github.com/golang/go/wiki/Modules which is slightly better but for some reason isn't in the official docs, and also basically brushes aside things like actually specifying v2+ modules in go.mod.

And as the article shows with links to examples, people forget to specify v2+ modules (yes, even Google forgets this), or just don't do the whole v2+ thing.

This is the clearest list of steps I've seen on the topic.

Reply on news.ycombinator.com