<story><title>An Analysis of vgo</title><url>https://sdboyer.io/vgo/intro/</url></story><parent_chain><item><author>TheDong</author><text>This rings as a wrong interpretation of history.&lt;p&gt;When git became successful, there were scant few other options with a comparable feature-set regardless of speed.&lt;p&gt;Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems.&lt;p&gt;I&amp;#x27;m unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more. This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.&lt;p&gt;In addition, git must be performant enough to handle a git repo (namely the linux kernel, its original usecase). Beyond that, I think there&amp;#x27;s no evidence it intentionally cut features or complexity to be faster.&lt;p&gt;In the case of vgo, it cuts additional user-facing features in order to be faster, but there&amp;#x27;s 0 evidence that the speed matters, that there are any go projects in the world that cannot be solved quickly enough with an approximation of a sat solver.</text></item><item><author>enqk</author><text>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&amp;#x27;s hard to know before hand what the healthy compromise might be.</text></item><item><author>pcwalton</author><text>The basic upshot of all this is that vgo&amp;#x27;s attempt to avoid NP-completeness in the dependency resolution algorithm is solving a problem that doesn&amp;#x27;t matter in practice, and is simultaneously creating downsides that &lt;i&gt;do&lt;/i&gt; matter in practice.&lt;p&gt;This is consistent with what I&amp;#x27;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 resolution algorithm wouldn&amp;#x27;t make the cut.</text></item></parent_chain><comment><author>lobster_johnson</author><text>My company was using Darcs at the time when git (mid-2008) was gaining popularity. Github wasn&amp;#x27;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.&lt;p&gt;At the time, the choice of git wasn&amp;#x27;t &lt;i&gt;that&lt;/i&gt; obvious. There were several popular, quite attractive contenders, including Mercurial, Monotone, Bazaar and GNU arch (and its forks), and it wasn&amp;#x27;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.&lt;p&gt;We&amp;#x27;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&amp;#x27;s ridiculous how often the paperclip solutions win over the more thoughtful ones.</text></comment>
<story><title>An Analysis of vgo</title><url>https://sdboyer.io/vgo/intro/</url></story><parent_chain><item><author>TheDong</author><text>This rings as a wrong interpretation of history.&lt;p&gt;When git became successful, there were scant few other options with a comparable feature-set regardless of speed.&lt;p&gt;Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems.&lt;p&gt;I&amp;#x27;m unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more. This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.&lt;p&gt;In addition, git must be performant enough to handle a git repo (namely the linux kernel, its original usecase). Beyond that, I think there&amp;#x27;s no evidence it intentionally cut features or complexity to be faster.&lt;p&gt;In the case of vgo, it cuts additional user-facing features in order to be faster, but there&amp;#x27;s 0 evidence that the speed matters, that there are any go projects in the world that cannot be solved quickly enough with an approximation of a sat solver.</text></item><item><author>enqk</author><text>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&amp;#x27;s hard to know before hand what the healthy compromise might be.</text></item><item><author>pcwalton</author><text>The basic upshot of all this is that vgo&amp;#x27;s attempt to avoid NP-completeness in the dependency resolution algorithm is solving a problem that doesn&amp;#x27;t matter in practice, and is simultaneously creating downsides that &lt;i&gt;do&lt;/i&gt; matter in practice.&lt;p&gt;This is consistent with what I&amp;#x27;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 resolution algorithm wouldn&amp;#x27;t make the cut.</text></item></parent_chain><comment><author>RVuRnvbM2e</author><text>&amp;gt; This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.&lt;p&gt;The thing is, modern dependency management tools for development suck. They are complex and slow and terribly unreliable.&lt;p&gt;A fresh, unconventional approach is needed, and vgo may be it.</text></comment>