Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Analysis of vgo

sdboyer.io

Post reply on HN
Print view View original

51–60 of 69 posts

Re: An Analysis of vgo

#51

Post by egl2019 »

TheDong wrote: post #19
enqk wrote: post #5

Earlier quoted context omitted.

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

This rings as a wrong interpretation of history. When git became successful, there were scant few other options with a comparable feature-set regardless of speed. Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems. I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more.…

Back when DCVS was just becoming a thing, I started with darcs and rather liked its model. I soon discovered that darcs had a nasty problem of quietly accepting large binary files that it could not manage -- you only discovered that the file was too large when you needed a revert or something similar. This led me to give up on darcs, and I switched to git. I could have gone to mercurial, but it appeared too sane and not as exotic.

Re: An Analysis of vgo

#52

Post by abiox »

i think one fundamental problem is that for most ecosystems, versioning is almost entirely arbitrary, manual and dissociated from language semantics.

the elm package manager seems to take a step in the right direction where changing a function signature will force a version bump if you want to publish the update. (iirc)

are there other languages/ecosystems that do something interesting with versioning?

Re: An Analysis of vgo

#53

Post by munificent »

nicpottier wrote: post #42

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point. I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very con…

> he is also "burying the lead" in that he never gets to the point.

He does say this is the first of a series of articles, so I think this is an uncharitable criticism. Dependency management is a very big topic and talking about it with sophistication — which you need to do to actually solve the problem well — takes a lot of words.

> I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples.

Sure, it's always easier to understand something when you talk about it in terms of small carefully-crafted examples. But with something like the emergent effects of dependency management tool UX choices on the health of a software ecosystem, you lose a lot when you limit your discussion to "here's what the algorithm does on these three toy packages".

Re: An Analysis of vgo

#54

Post by littlestymaar »

enqk wrote: post #5
pcwalton wrote: post #3

The basic upshot of all this is that vgo's attempt to avoid NP-completeness in the dependency resolution algorithm is solving a problem that doesn't matter in practice, and is simultaneously creating downsides that do matter in practice. This is consistent with what I've seen with systems like Cargo. If I had to make a list of top 10 issues I run into with Cargo, theoretical scalability of the core dependency resolut…

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

You compare vgo to git but I think your comparison is backward, in regard of not solving “hard theoretical problems” git is more like current package manager. They don't care about the hypothetical NP-hardness of the problem. Vgo is an attempt to work-around this hard theoretical problem that doesn't even matter in practice.

Re: An Analysis of vgo

#55

Post by munificent »

paulsutter wrote: post #24
lobster_johnson wrote: post #15

Earlier quoted context omitted.

git may have become successful, but that doesn't mean it's right. I'd argue that most developers still don't really understand git. I know seasoned, senior developers who struggle when git gets into an unfamiliar state, or who are completely mystified as to how it actually works. And don't forget that git spent years improving its initially horrific UI to make it easier and more palatable to people who aren't kernel…

Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects. Something better could be even more right, and adoption would be the measure. > git may have become successful, but that doesn't mean it's right.

> Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects.

Your statement is only true to the degree that it's a tautology: Git's popularity demonstrates that it's right and the definition of "right" is "popular".

But if you want to use "right" to mean anything else, maybe to say something about it's technical merits independent of sociological factors like the network effect, first-mover advantage, high-profile early adopter, etc. then your sentence doesn't add any information.

Personally, I think Git's user experience is an unremitting shitshow, the kind of disaster that makes one reconsider Hanlon's Razor.

The technical capabilities buried under that UX are pretty nice, though you could probably discard 1/3 of them without impacting any noticeable fraction of users.

The performance is excellent and it's very easy for developers to underrate how much that effects user satisfaction.

And it had the good fortune to win on almost all of the sociological factors that largely determine product success.

Re: An Analysis of vgo

#56

Post by geodel »

IshKebab wrote: post #7

This badly needs a TL;DR. If there's something seriously wrong with vgo's dependency versioning then it should be possible to explain it in less than 100k words.

I am afraid it is because lot of expectations were built that dep author would reveal some rather serious flaws with vgo. But since he has nothing explicit, many thousand words are required to cover that up.

Re: An Analysis of vgo

#57

Post by munificent »

red_admiral wrote: post #12

> If there are two algorithms that satisfy the same requirements, and only one is NP-complete, you pick the other one. Problems can be NP-complete. Algorithms cannot - they can be exponential time (and if your choice is between exponential and double exponential, you pick the former!) In practice, and especially for SAT solving, as far as I understand the state of the art is that the general case is NP-hard but we ha…

> In practice, and especially for SAT solving, as far as I understand the state of the art is that the general case is NP-hard but we have tools that work surprisingly well in those cases that reality tends to produce.

You're correct. Modern version solvers need fairly sophisticated algorithms, but it's not rocket science. It's mostly a non-problem for most users of most package managers most of the time.

Re: An Analysis of vgo

#58

Post by steveklabnik »

abiox wrote: post #52

i think one fundamental problem is that for most ecosystems, versioning is almost entirely arbitrary, manual and dissociated from language semantics. the elm package manager seems to take a step in the right direction where changing a function signature will force a version bump if you want to publish the update. (iirc) are there other languages/ecosystems that do something interesting with versioning?

We're working on similar tooling to that in Rust https://github.com/rust-lang-nursery/rust-semverver

Re: An Analysis of vgo

#59

Post by lobster_johnson »

TheDong wrote: post #19
enqk wrote: post #5

Earlier quoted context omitted.

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

This rings as a wrong interpretation of history. When git became successful, there were scant few other options with a comparable feature-set regardless of speed. Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems. I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more.…

My company was using Darcs at the time when git (mid-2008) was gaining popularity. Github wasn't around yet. At the time, git felt like a big step backwards technologically. It had a terrible UI, and the whole thing felt like something put together with tape and paperclips. Meanwhile, Darcs was (and still is) pure magic.

At the time, the choice of git wasn't that obvious. There were several popular, quite attractive contenders, including Mercurial, Monotone, Bazaar and GNU arch (and its forks), and it wasn't obvious who would win. But then Github arrived and changed everything, and it felt like everyone was suddenly caught up in a historic momentum whether they liked it or not.

We've had lots of those historic moments, some of them more slow-moving than others. Mac and NeXT being outmaneouvered by Windows; Lisp, Dylan and Smalltalk being relegated to the dustbin through the rise of more popular, worse languages; and so on. Not all of these developments are terrible (I love that Nginx prevailed over Apache and that Rails took over from Java app servers), but it's ridiculous how often the paperclip solutions win over the more thoughtful ones.

Re: An Analysis of vgo

#60

Post by zellyn »

enqk wrote: post #5
pcwalton wrote: post #3

The basic upshot of all this is that vgo's attempt to avoid NP-completeness in the dependency resolution algorithm is solving a problem that doesn't matter in practice, and is simultaneously creating downsides that do matter in practice. This is consistent with what I've seen with systems like Cargo. If I had to make a list of top 10 issues I run into with Cargo, theoretical scalability of the core dependency resolut…

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

That's the same hand. Unless I'm misunderstanding, pcwalton said that solving the hard theoretical problem doesn't even rate on his list.
Post reply on HN