Item — HN Reader

You can emulate traditional dependency management by pinning the versions of all your scraps, and updating them selectively:

  user/my-scrap@414

> This fixer would have to walk the dependency tree.

Remember that the language itself works like a merkle tree and every scrap can be cached anywhere. To keep the language and tooling extremely simple, I think this works well enough.

> What if something breaks contract in the middle, something I do not control?

Everything is strongly typed, so there are certain guarantees about how things can break and update. You can easily make tooling that never makes breaking changes.

People can always introduce implementation bugs into their code though, but that's inevitable even with dependency management.

> That sounds like a huge burden on developers with lots of risk.

I will try my hardest to reduce that burden. I think I can put some sane defaults in the tooling surrounding the language to obviate the need for traditional dependency management.

1 comments

So the issue is see with lack of dep management...

1. My code depends on dep A and B, which also depends on A.

2. A has some issue, so I update my reference, but B does not.

3. Given dependencies are bundled, B still contains the bad A.

So how can I updated the A used by B? (Without effectively forking B) This is more a problem with bundled or censored dependencies than the lack of dependency management. Dep Mgmt aims to solve this issue by having only one copy of a dependency

Except in many dep management systems they purposefully don’t keep only one copy to allow multi versions to run side by side and other benefits like having a deliberate piece by piece upgrade of everything in the dependency tree. Forcing all deps to be on the same version of all other deps sounds like it would cause more problems than it would solve.

Also the ideas of immutable deps mean this property of “duplicated” deps comes naturally.

I think many bugs can come from what you propose. A large dev tree would need everyone in the tree to coordinate to upgrade all at once. That seems basically impossible for any dep tree. Especially in a system where the deps are small code snippets like this one. Even small programs can have 1000s of deps.

Why are you implying that this model is “normal” dep management?

Aka “the diamond dependency problem”.

If the “old” A has a severe vulnerability and the “new” A has breaking changes - then there is no solution other than to avoid/replace/fork B until B is upgraded.