6 ms·

I've been using go modules in my company for several months now. Everything has "just worked." It's at least 1 order of magnitude faster than dep. It's worth n

I've been using go modules in my company for several months now. Everything has "just worked." It's at least 1 order of magnitude faster than dep. It's worth noting that go modules use a novel dependency resolution algorithm which is extremely simple to reason about/implement, fast, and produces more reliable builds than npm/bundler/cargo. That's why I was excited about it, anyway. It removes the ever-present NP-complete assumptions in this space, so from a computer science perspective it's extremely interesting.

weberc2 8y ago
Can you elaborate on why it’s easier to reason about than Cargo et al? I’ve heard a lot of theoretical criticism of Go modules for not taking Cargo’s approach so I’m surprised to hear an experience report to the contrary.
- hellcow 8y ago
  I can't do much justice to the topic in a HN post, but this post specifically describes Go module's dependency resolution algorithm and compares it against SAT solvers like Cargo's: https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs. Click the "Go & Versioning" link in the header, and you'll find a whole series explaining the design decisions.
- dilap 8y ago
  From cargo's source: "Actually solving a constraint graph is an NP-hard problem. This algorithm is basically a nice heuristic to make sure we get roughly the best answer most of the time." (https://github.com/rust-lang/cargo/blob/master/src/cargo/core/resolver/mod.rs https://github.com/rust-lang/cargo/blob/master/src/cargo/cor...) vgo's more-constrained specification for dependencies means there is exactly one right answer, and it can be easily and quickly calculated by both computer and human. Whether or not this will turn out to matter in practice is still an open question.
  - flurrything 8y ago
    Is there a catch to vgo's approach? If not, why aren't the cargo people copying it?
    - codezero 8y ago
      I’m no expert, and I might even be very wrong, but I read the post about it and it seems to hinge on only resolving a minimum version and assuming all future packages with the same import path are backwards compatible. If I’m reading right it basically treats path/to/package and path/to/package/v2 as entiresly different packages.
      - eikenberry 8y ago
        You are correct. It bakes semantic versioning into the dependency system making it a requirement vs. just a convention.
    - civility 8y ago
      As a rule, Rust and Cargo developers aren't satisfied with something until it's difficult to explain and complicated to implement.
    - dragonwriter 8y ago
      The catch to the vgo approach required that no package in the ecosystem ever have even unintentional backwards incompatibilities, because you can't do anything other than specify minimum versions. Or, rather, it makes the resulting problems something that need to be addressed outside the scope of dependency specification and resolution. When you just decide not to address a significant part of the problem, the solution becomes simpler.
      - eikenberry 8y ago
        > unintentional backwards incompatibilities You mean a bug? Because that's what that is and it is no different from any other bug, and like any other bug they are outside the scope of dependency specifications as they are unintended.
stephen 8y ago
> novel dependency resolution algorithm I've heard/read this, but I can't tell what is necessarily novel about it...to me, it reads like old-school/boring Maven transitive dependency resolution. (Not holding out maven as best practice, it's just what I know best in terms of pre-version ranges, pre-lock file dependency management, once those features become state of the art in ~2010.) ...that said, Maven does actually support version ranges; ~10 years ago when I last used it, either it didn't support them then, or we didn't use it, so perhaps that is why vgo seems so familiar. Or I just have a terrible memory. Anyway, if anyone can correct me on my fuzzy assertion that "vgo is like maven w/fixed versions", I'd appreciate it!

weberc2 8y ago

Can you elaborate on why it’s easier to reason about than Cargo et al? I’ve heard a lot of theoretical criticism of Go modules for not taking Cargo’s approach so I’m surprised to hear an experience report to the contrary.

hellcow 8y ago
I can't do much justice to the topic in a HN post, but this post specifically describes Go module's dependency resolution algorithm and compares it against SAT solvers like Cargo's: https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs. Click the "Go & Versioning" link in the header, and you'll find a whole series explaining the design decisions.
dilap 8y ago
From cargo's source: "Actually solving a constraint graph is an NP-hard problem. This algorithm is basically a nice heuristic to make sure we get roughly the best answer most of the time." (https://github.com/rust-lang/cargo/blob/master/src/cargo/core/resolver/mod.rs https://github.com/rust-lang/cargo/blob/master/src/cargo/cor...) vgo's more-constrained specification for dependencies means there is exactly one right answer, and it can be easily and quickly calculated by both computer and human. Whether or not this will turn out to matter in practice is still an open question.
- flurrything 8y ago
  Is there a catch to vgo's approach? If not, why aren't the cargo people copying it?
  - codezero 8y ago
    I’m no expert, and I might even be very wrong, but I read the post about it and it seems to hinge on only resolving a minimum version and assuming all future packages with the same import path are backwards compatible. If I’m reading right it basically treats path/to/package and path/to/package/v2 as entiresly different packages.
    - eikenberry 8y ago
      You are correct. It bakes semantic versioning into the dependency system making it a requirement vs. just a convention.
  - civility 8y ago
    As a rule, Rust and Cargo developers aren't satisfied with something until it's difficult to explain and complicated to implement.
  - dragonwriter 8y ago
    The catch to the vgo approach required that no package in the ecosystem ever have even unintentional backwards incompatibilities, because you can't do anything other than specify minimum versions. Or, rather, it makes the resulting problems something that need to be addressed outside the scope of dependency specification and resolution. When you just decide not to address a significant part of the problem, the solution becomes simpler.
    - eikenberry 8y ago
      > unintentional backwards incompatibilities You mean a bug? Because that's what that is and it is no different from any other bug, and like any other bug they are outside the scope of dependency specifications as they are unintended.

stephen 8y ago

> novel dependency resolution algorithm I've heard/read this, but I can't tell what is necessarily novel about it...to me, it reads like old-school/boring Maven transitive dependency resolution. (Not holding out maven as best practice, it's just what I know best in terms of pre-version ranges, pre-lock file dependency management, once those features become state of the art in ~2010.) ...that said, Maven does actually support version ranges; ~10 years ago when I last used it, either it didn't support them then, or we didn't use it, so perhaps that is why vgo seems so familiar. Or I just have a terrible memory. Anyway, if anyone can correct me on my fuzzy assertion that "vgo is like maven w/fixed versions", I'd appreciate it!