5 ms·

To add, making the version part of the namespace is the right thing to do, also because it avoids conflicts with transitive dependencies. Changing the namespace

• grey-area 6y ago
  Accretion of features should be preferable to breakage. I think most people, particularly those using Go, would agree with this. It does not follow that we should make breaking changes easier or routine, nor that we should force people to use strict semver (which is not widely used for good reasons). I see why they've done that as it simplifies assumptions but prefer the way other package managers handle this where it is left to producers and consumers to negotiate how strict they want to be.
• stubish 6y ago
  > Changing the namespace means that the same project can depend on multiple different major versions of the same library. Do you actually want that? Do you actually know that the multiple versions of the dependency you happen to be using do not conflict? If the dependency is in different namespaces their locks and other globals are also in different namespaces.
  • bad_user 6y ago
    Yes, I do, because this isn't just about my source-code, but about the dependencies of dependencies.
    • grey-area 6y ago
      The two approaches to this are to force resolving dependencies (can be painful and require humans), or duplicate code (can cause bugs). There are disadvantages to both and in particular duplicating dependencies should be seen as a short-term fix for a transition, not something you do routinely. If you do it routinely you'd see bugs due to shared locks, state, or changed data structures - it breaks assumptions about pkg globals for example, an important part of the language used extensively in the stdlib.
      • yxhuvud 6y ago
        Or even conflicts rising from competing use of state space in some other app. For example, if your database have a limited set of connections it can set up then you absolutely don't want different dependencies to handle connection pooling by themselves.
      • imtringued 6y ago
        >There are disadvantages to both and in particular duplicating dependencies should be seen as a short-term fix for a transition, not something you do routinely. If you don't duplicate versions then you will have to wait for every single library in existence to update to the latest major version. This can take decades and still fail. Just take a look at Python 3.
    • stubish 6y ago
      So yes, you want that. But how about the next question? The dependencies of your dependencies may conflict with different versions of themselves. Because nobody thought 'what happens if there is another version of this code running in a different namespace'. And nobody tested it, so you are trusting to luck rather than any sort of rigor. Thankfully, the conflicts when they happen are usually fairly obvious (two copies of the connection pool built into your database driver, or a crash on startup because the run-once initialization ends up being run twice). But it could be more subtle, like multiple versions of the dependency that handles logging not sharing a mutex and your logs end up interleaved or corrupt under load.
  • rad_gruchalski 6y ago
    Yes! This is exactly why people do shading in Java!
• FreeFull 6y ago
  It's not like putting the version into the namespace is necessary for this, though. Rust's Cargo will let you use multiple versions of a library too, without extra namespacing.
  • blablabla123 6y ago
    ...and needs a package manager to solve NP-complete dep hell: https://research.swtch.com/version-sat https://research.swtch.com/version-sat Go's package management is really well designed I think and also actually semantically relying on semver