Hacker News Reader

Comment by bad_user | Hacker News Reader

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 means that the same project can depend on multiple different major versions of the same library.

And that's fine, because when you break compatibility, you're actually not talking about the same library. And this makes upstream developers think twice about breaking compatibility. Accretion of features should be preferable to breakage.

It's what Rich Hickey talks about in his Spec-ulation talk: https://www.youtube.com/watch?v=oyLBGkS5ICk

View on HN

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.

...and needs a package manager to solve NP-complete dep hell: https://research.swtch.com/version-sat

Go's package management is really well designed I think and also actually semantically relying on semver

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.

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

Yes, I do, because this isn't just about my source-code, but about the dependencies of dependencies.

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.

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.

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

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.

Yes! This is exactly why people do shading in Java!

Reply on news.ycombinator.com