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

21–30 of 69 posts

Re: An Analysis of vgo

#21

Post by closeparen »

TheDong wrote: post #17
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.

> If there's something seriously wrong with vgo's dependency versioning then it should be possible to explain it in less than 100k words. That is a very lazy argument. It's perfectly reasonable to claim something is flawed for numerous complex reasons. It's equally reasonable to claim that a complex flaw may be difficult to explain concisely. Most importantly though, I don't think Sam is claiming that there's an obvi…

The post could stand to have an introduction that lays out its arguments at a high level, as is hammered into students at every level of English class.

Re: An Analysis of vgo

#22

Post by enqk »

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.…

Darcs was one of the well-known examples that could be brandished

Re: An Analysis of vgo

#23

Post by coldtea »

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.

>On the other hand, git became successful by being fast

In a totally different domain with involves working diffs for and managing gigabytes of source code....

Re: An Analysis of vgo

#24

Post by paulsutter »

lobster_johnson wrote: post #15
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.

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.

Re: An Analysis of vgo

#25

Post by rosshemsley »

Anyone have a bullet-pointed summary of the "crux" of what the author dislikes about MVS?

I find MVS to be a very natural and simple solution to versioning - I feel like it's much closer to how people actually manage their dependencies in practice.

After an admittedly low-effort skim of this article, most of the arguments seem to be that the author doesn't think it "feels right". Is there something more concrete hidden in here?

Re: An Analysis of vgo

#26

Post by kasey_junk »

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.

Gits adoption was driven by github, which won by making public repos free & private repos cost.

If bitbucket had that business model instead of the inverse we’d all think of git as that weird bad hg that Linus forces the Linux devs to use.

Git is a classic example of other factors than the software driving use.

Re: An Analysis of vgo

#28

Post by endymi0n »

lobster_johnson wrote: post #9
pcx wrote: post #4

I think the current approach of announcing the death of `dep` before even having a stable alternative (`vgo`) is deeply flawed. With `dep` the ecosystem finally had something most of the developers agreed on, despite whatever shortcomings it had. The model was working. They could have adopted dep and improved on it. The packaging story for Golang has gone from worse to OK to worse again. After all this progress, we s…

I don't disagree — dep has been a huge improvement on Go's package management story. Until dep was stable, we were using Glide, which is extremely buggy. That said, if you ignore the doubts and arguments about the sanity of its dependency resolution algorithm, I think vgo's introduction of modules is its real contribution. Go packages have been problematic since the start since their design, naively, conflates a bunc…

All of this feels like a classic case of "the perfect is the enemy of the good". Package and dependency management in Go is honestly a total mess today and with vgo challenging all current assumptions about how to generally approach packagement, it brings complete paralysis to the simple question of "how should I organize my dependencies right now".

As much as I loathe JavaScript or Ruby these days for their language, using npm or bundler simply feels sane despite all of their warts. Yes, `left-pad`. Yes, they do have their issues. But seriously, they just work and all open source packages comply to their specifications. And they can and do evolve gradually, like yarn shows.

It's just so funny how careful the Go community seems to tread about not breaking their language with all these Go 2 proposals and general resistance to new features — and then completely ignore this spirit to "move fast and break things" when it comes to package management.

Re: An Analysis of vgo

#29

Post by cdoxsey »

rosshemsley wrote: post #25

Anyone have a bullet-pointed summary of the "crux" of what the author dislikes about MVS? I find MVS to be a very natural and simple solution to versioning - I feel like it's much closer to how people actually manage their dependencies in practice. After an admittedly low-effort skim of this article, most of the arguments seem to be that the author doesn't think it "feels right". Is there something more concrete hidd…

Its a long post, but I don't think he actually gives the reasons, rather he intends to write several additional posts that will.

Re: An Analysis of vgo

#30

Post by sagichmal »

ngrilly wrote: post #16
pcx wrote: post #4

I think the current approach of announcing the death of `dep` before even having a stable alternative (`vgo`) is deeply flawed. With `dep` the ecosystem finally had something most of the developers agreed on, despite whatever shortcomings it had. The model was working. They could have adopted dep and improved on it. The packaging story for Golang has gone from worse to OK to worse again. After all this progress, we s…

> They could have adopted dep and improved on it. Not really because: - The scope is different. dep is a package management tool. vgo is more than that. vgo intends to fully replace the go command. This is how we deprecate GOPATH. - The underlying principles are different enough to make it difficult to "improve" on dep. It looked easier to start from scratch. References: "Go += Package Versioning", Russ Cox, https://…

dep was always written with the intention that it would be merged into or replace to go tool. And it's still not settled that the underlying principles of vgo are valid -- which this article begins to unpack.
Post reply on HN