6 ms·

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

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.

jacquesm 6y ago
It's actually pretty much the only consistent and guaranteed backwards compatible way to deal with such changes.
- barrkel 6y ago
  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.
  - roskilli 6y ago
    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.
    - barrkel 6y ago
      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.
- ubertaco 6y ago
  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.
dmitriid 6y ago
> 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 https://news.ycombinator.com/item?id=24432511
- geodel 6y ago
  Its been covered in detail here: https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules
  - dmitriid 6y ago
    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 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.
barrkel 6y ago
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.
justicezyx 6y ago
> 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.
- apta 6y ago
  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#.
matthewmueller 6y ago
This is the clearest list of steps I've seen on the topic.

jacquesm 6y ago

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

barrkel 6y ago
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.
- roskilli 6y ago
  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.
  - barrkel 6y ago
    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.
ubertaco 6y ago
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.

dmitriid 6y ago

> 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 https://news.ycombinator.com/item?id=24432511

geodel 6y ago
Its been covered in detail here: https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules
- dmitriid 6y ago
  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 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.

barrkel 6y ago

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.

justicezyx 6y ago

> 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.

apta 6y ago
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#.

matthewmueller 6y ago

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