7 ms·

Definitely not. Nothing here is particularly novel, `vgo` just stakes out a different position on all of the relevant spectrums than most (all) other package ma

Definitely not. Nothing here is particularly novel, `vgo` just stakes out a different position on all of the relevant spectrums than most (all) other package managers.

xyzzy_plugh 9y ago
I, too, am unfamiliar with prior art here. Are you able enlighten us?
- sagichmal 9y ago
  Not in a Hacker News comment, sorry; the space is just too big.
- platz 9y ago
  Haskell's build tool Cabal also uses a solver that produces a concrete build solution that takes into account dependency bounds. It uses slightly different rules for the solver than what vgo uses.
mseepgood 9y ago
The same could be said about 'gofmt' in relation to all the pretty printers that existed before, yet it was revolutionary.
- sagichmal 9y ago
  That's a stretch.
- pcwalton 9y ago
  gofmt is only revolutionary in that it refuses to solve the hard problems that pretty printers for other languages solve. Specifically, it doesn't wrap long lines--ever--even though making visually pleasing line breaking choices is pretty much the hardest part of pretty printing (look at how clang-format deals with it, for instance). This design decision would be a non-starter for almost all other languages, where long lines occasionally happen. In other words, gofmt showed that it's easy to write a pretty printer if you ignore line breaking and instead force everyone to accept long lines. This is not a particularly interesting, and certainly not revolutionary, result. (Not coincidentally, I have similar concerns regarding this Go versioning proposal and lockfiles.)
  - Skinney 9y ago
    elm-format doesn't wrap long lines either. I'm not sure it would be a good thing if it did, to be honest.
  - eikenberry 9y ago
    > [...] instead force everyone to accept long lines. You don't need to accept long lines as gofmt respects your own line wrapping. It's easy to write code that never exceeds the 80 character limit. The main annoyance in go is it's use of tabs, so you have to change tabs in everything to a reasonable amount of space.
    - pcwalton 9y ago
      Fair enough; that's a good point. I'd still argue, though, that gofmt isn't doing what people expect pretty printers to do. Long lines are some of the most common style violations in most projects.
      - eikenberry 9y ago
        100% agreed. I'm a strong believer that the 4-6 inch column rule from print media applies equally to text in general and that the 80 character rule is a good approximation for this print rule.
  - peterevans 9y ago
    A pretty printer, historically—going all the way back to indent—allowed the user to define a bespoke style guide, with a specific indent level, with one way to align braces, etc. You could implement GNU-style C code with indent; you could implement Allman-style C code; you could mix in your own preference for indent level. As such, I think your complaints are misplaced. gofmt is not a pretty printer. It's designed to implement a single standard format—one which does not define a maximum line width—but nothing more.
    - pcwalton 9y ago
      The purpose of a pretty printer is to increase readability of code. (This isn't controversial.) One of the most important aspects of code readability is line length. By not addressing that, gofmt isn't fully solving the problem that pretty printers are designed to solve. Indent, by the way, allows for a maximum line length.
dilap 9y ago
Nah, it's totally novel -- it's a viable packaging system that isn't NP-hard. Is there any precedent for that? It's also likely, in practical terms, to feel very different to work with than any existing packaging system. My money is on it becoming quite popular. It just feels like it's been sprinkled w/ the Go magic -- deceptively simple ideas that end up working really well.
- kibwen 9y ago
  > it's a viable packaging system that isn't NP-hard. Is there any precedent for that? Yes, Rust's Cargo: see https://github.com/rust-lang/cargo/blob/0.25.0/src/cargo/core/resolver/mod.rs#L9-L36 https://github.com/rust-lang/cargo/blob/0.25.0/src/cargo/cor... For demonstration, on my low-end VPS Cargo takes less than a quarter second to select the versions of the 289 transitive dependencies used by Servo (could be much less, but I don't have a precise measurement; `time cargo update` takes 1.22 seconds but this is dominated by the network calls checking for a new version of the crates.io index and checking for new versions of Servo's custom deps on Github). The fact that the algorithm in the OP isn't NP-hard isn't anything worth getting excited about. The only advantage I can see is that it gives a measure of reproducibility without the need for lockfiles--though builds will still be less reproducible than they'd be with lockfiles.
  - bradfitz 9y ago
    > > it's a viable packaging system that isn't NP-hard. Is there any precedent for that? > Yes, Rust's Cargo: https://github.com/rust-lang/cargo/blob/master/src/cargo/cor.. https://github.com/rust-lang/cargo/blob/master/src/cargo/cor.... For comparison, on my low-end VPS Cargo takes less than a quarter second to select the versions of the 289 transitive dependencies used by Servo That's kinda an answer to a different question. The question you replied to was asking about other non-NP-hard systems and you replied with how much time your system took.
    - kibwen 9y ago
      If you take a moment to read the linked comment, you will see that it describes how Cargo's selection algorithm is a simple heuristic that avoids NP-hardness. The subsequent timing example exists to demonstrate that the heuristic actually succeeds at avoiding pathological performance; Servo has more transitive dependencies than any known Rust project, and your development box is certainly more powerful than my $5 VPS.

Definitely not. Nothing here is particularly novel, `vgo` just stakes out a different position on all of the relevant spectrums than most (all) other package managers.

xyzzy_plugh 9y ago

I, too, am unfamiliar with prior art here. Are you able enlighten us?

sagichmal 9y ago
Not in a Hacker News comment, sorry; the space is just too big.
platz 9y ago
Haskell's build tool Cabal also uses a solver that produces a concrete build solution that takes into account dependency bounds. It uses slightly different rules for the solver than what vgo uses.

mseepgood 9y ago

The same could be said about 'gofmt' in relation to all the pretty printers that existed before, yet it was revolutionary.

sagichmal 9y ago
That's a stretch.
pcwalton 9y ago
gofmt is only revolutionary in that it refuses to solve the hard problems that pretty printers for other languages solve. Specifically, it doesn't wrap long lines--ever--even though making visually pleasing line breaking choices is pretty much the hardest part of pretty printing (look at how clang-format deals with it, for instance). This design decision would be a non-starter for almost all other languages, where long lines occasionally happen. In other words, gofmt showed that it's easy to write a pretty printer if you ignore line breaking and instead force everyone to accept long lines. This is not a particularly interesting, and certainly not revolutionary, result. (Not coincidentally, I have similar concerns regarding this Go versioning proposal and lockfiles.)
- Skinney 9y ago
  elm-format doesn't wrap long lines either. I'm not sure it would be a good thing if it did, to be honest.
- eikenberry 9y ago
  > [...] instead force everyone to accept long lines. You don't need to accept long lines as gofmt respects your own line wrapping. It's easy to write code that never exceeds the 80 character limit. The main annoyance in go is it's use of tabs, so you have to change tabs in everything to a reasonable amount of space.
  - pcwalton 9y ago
    Fair enough; that's a good point. I'd still argue, though, that gofmt isn't doing what people expect pretty printers to do. Long lines are some of the most common style violations in most projects.
    - eikenberry 9y ago
      100% agreed. I'm a strong believer that the 4-6 inch column rule from print media applies equally to text in general and that the 80 character rule is a good approximation for this print rule.
- peterevans 9y ago
  A pretty printer, historically—going all the way back to indent—allowed the user to define a bespoke style guide, with a specific indent level, with one way to align braces, etc. You could implement GNU-style C code with indent; you could implement Allman-style C code; you could mix in your own preference for indent level. As such, I think your complaints are misplaced. gofmt is not a pretty printer. It's designed to implement a single standard format—one which does not define a maximum line width—but nothing more.
  - pcwalton 9y ago
    The purpose of a pretty printer is to increase readability of code. (This isn't controversial.) One of the most important aspects of code readability is line length. By not addressing that, gofmt isn't fully solving the problem that pretty printers are designed to solve. Indent, by the way, allows for a maximum line length.

dilap 9y ago

Nah, it's totally novel -- it's a viable packaging system that isn't NP-hard. Is there any precedent for that? It's also likely, in practical terms, to feel very different to work with than any existing packaging system. My money is on it becoming quite popular. It just feels like it's been sprinkled w/ the Go magic -- deceptively simple ideas that end up working really well.

kibwen 9y ago
> it's a viable packaging system that isn't NP-hard. Is there any precedent for that? Yes, Rust's Cargo: see https://github.com/rust-lang/cargo/blob/0.25.0/src/cargo/core/resolver/mod.rs#L9-L36 https://github.com/rust-lang/cargo/blob/0.25.0/src/cargo/cor... For demonstration, on my low-end VPS Cargo takes less than a quarter second to select the versions of the 289 transitive dependencies used by Servo (could be much less, but I don't have a precise measurement; `time cargo update` takes 1.22 seconds but this is dominated by the network calls checking for a new version of the crates.io index and checking for new versions of Servo's custom deps on Github). The fact that the algorithm in the OP isn't NP-hard isn't anything worth getting excited about. The only advantage I can see is that it gives a measure of reproducibility without the need for lockfiles--though builds will still be less reproducible than they'd be with lockfiles.
- bradfitz 9y ago
  > > it's a viable packaging system that isn't NP-hard. Is there any precedent for that? > Yes, Rust's Cargo: https://github.com/rust-lang/cargo/blob/master/src/cargo/cor.. https://github.com/rust-lang/cargo/blob/master/src/cargo/cor.... For comparison, on my low-end VPS Cargo takes less than a quarter second to select the versions of the 289 transitive dependencies used by Servo That's kinda an answer to a different question. The question you replied to was asking about other non-NP-hard systems and you replied with how much time your system took.
  - kibwen 9y ago
    If you take a moment to read the linked comment, you will see that it describes how Cargo's selection algorithm is a simple heuristic that avoids NP-hardness. The subsequent timing example exists to demonstrate that the heuristic actually succeeds at avoiding pathological performance; Servo has more transitive dependencies than any known Rust project, and your development box is certainly more powerful than my $5 VPS.