[alexmingoia]

The diamond dependency problem is easy to avoid: Only allow namespaced/qualified includes, no shared libraries. There is no need for a package manager if the runtime does the work of resolving all includes, and these references have some kind of cryptographic integrity.

This can be completely transparent to the user. There's no need to have a separate program do dependency resolution when dependencies are referenced in source code. Instead we have the complete waste of life that is package manifests and shared libraries.

[kubanczyk]

If you are not doing shared dependencies, count me out.

[alexmingoia]

Why is that?

To be clear the lack of “shared” dependencies does not necessitate code duplication. By shared dependencies I’m talking about languages (Haskell for example) where only one version of a library can be used, which results in the diamond dependency problem (predictably so!).

Let’s say file A references file B and C, and files B and C both reference D. D doesn’t need to be duplicated.

If all includes are qualified/namespaced there is no diamond dependency problem, and the compiler/runtime can reuse the same code for multiple references to the same file.

[kubanczyk]

> Let’s say file A references file B and C, and files B and C both reference D. D doesn’t need to be duplicated.

Yes, if an ecosystem does not attempt to ensure that D is at a single version, which is both B-compatible and C-compatible, it moves a mountain of complexity onto A.

It might not be apparent for a small program that only uses standard library and never experiences diamond dependencies at all. But the complexity here is that

1. A might get a D1 object/structure/result from B, and later

2. A might get a D2 object/structure/result from C, and then

3. Some code may be needed to ensure D1 compatibility with D2, if they interact. This problem is better to be resolved in an ecosystem than in A.