4 ms·

It's worth noting that the one version policy is a technical requirement for linking compiled languages together. Yes, there are organizational reasons to requi

It's worth noting that the one version policy is a technical requirement for linking compiled languages together. Yes, there are organizational reasons to require exactly one version of a project. But compiled languages, especially C++, will do Very Bad Things if you have versioning inconsistencies. It's possible to be intentionally ABI compatible in certain ways for certain lengths of time, but scaled over time, number of concurrent versions of a project, and number of downstream uses, you're just waiting to be burnt hard. That being said, it's possible to do version pinning carefully at the executable level, just so long as each executable has exactly one version of each dependency in its dependency graph. But then you have a combinatorial explosion of dependency sets to evaluate and support. Theoretically possible, but not very practical. ABI stable languages and languages that ship as source code have a much smaller analysis space since compatibility can be assumed in many more situations.

bombcar 5y ago
You also have to worry about programmers being api compatible- if someone moves from project A using lib v1.3 they may not realize project N is using lib 1.4 with some differences.
anothernewdude 5y ago
You can pin multiple versions of the same dependency, just not with the shitty ldd you're thinking of. Or avoid dynamic linking altogether. Rust lets you have multiple versions of the same crate living in the same executable.
- humanrebar 5y ago
  Statically linking doesn't necessarily fix this. Nor does ensuring only one version is actually linked. The problem starts when different dependencies have different opinions about ABI-important details. Like layout of data structures, layout of v-tables, use of concurrency primitives, or even stack utilization. I don't have as much depth of knowledge in cargo (rustc probably can't avoid these problems). From what I can tell, it prefers resolving dependency sets per executable, which means it would be opting for the combinatorial explosion of compatibility sets problem. That's a valid tradeoff to select, though I am extremely skeptical that an organization with 30k Rust projects would find that dependency juggling is a non-problem.

bombcar 5y ago

You also have to worry about programmers being api compatible- if someone moves from project A using lib v1.3 they may not realize project N is using lib 1.4 with some differences.

anothernewdude 5y ago

You can pin multiple versions of the same dependency, just not with the shitty ldd you're thinking of. Or avoid dynamic linking altogether. Rust lets you have multiple versions of the same crate living in the same executable.

humanrebar 5y ago
Statically linking doesn't necessarily fix this. Nor does ensuring only one version is actually linked. The problem starts when different dependencies have different opinions about ABI-important details. Like layout of data structures, layout of v-tables, use of concurrency primitives, or even stack utilization. I don't have as much depth of knowledge in cargo (rustc probably can't avoid these problems). From what I can tell, it prefers resolving dependency sets per executable, which means it would be opting for the combinatorial explosion of compatibility sets problem. That's a valid tradeoff to select, though I am extremely skeptical that an organization with 30k Rust projects would find that dependency juggling is a non-problem.