Comment by _pfxa | Hacker News Reader

Comment by _pfxa | Hacker News Reader

I still wonder why solving a solved problem took so long to solve for the Go community, given they already solved it anyways?

That is, in more proper words, first of all, language specific package management is mostly a solved problem. There are possible improvements, and maybe vgo realises some of them, but that's mostly a bikeshedding problem. What users need is to be able to declare what packages they need, in what version range. And their search for an alternative to fetching source repos is like searching for the cure to ilnesses that already have proven vaccines: you just put up a server and fetch from there. Decentralisation? Put up mirrors.

Then the way this vgo thing happened is the opposite of nice. Tools already existed, and they had to conform to the restrictions of the project (like the, excuse me but, idiotic idea of a $GOPATH); but then one of the Go deities come around and goes, um, I deprecate all of you, break the rules that you had to comply, and because I-am-who-I-am, this is the way to go.

Now Cox's solution might indeed be better (though I think it's an overkill, and do agree to Boyer's articles I read), but this is not the way to run a community. From my PoW, this would not preclude me from using the language if it came up, but I'd definitely be reluctant to send patches to them. Communities with deities and dogmas are always unhealthy. Those that also, additionally, are deep down in yak shaving and bikeshedding are even more so.

> Now Cox's solution might indeed be better (though I think it's an overkill ...

vgo is actually much, much simpler than dep. The sheer number of words in Russ Cox's series of blog posts belies its simplicity. vgo doesn't need a SAT solver. If you look at many of the issues dep is struggling with, they're related to solving N libraries with transitive dependencies up the wazoo.

Cox's long treatise reflects the complexity of the problem space. Developers tend to brush off package management as being simple. But once you include range-based version constraints and transitive dependencies, it gets a bit messier. Look at NPM and Yarn; they're still struggling to get all the details right. On the other hand, there's Ruby's Bundler. It came out in 2009, RubyGems in 2004, and I've never had a single issue with the toolchain (other than messing up my own constraints). I don't know what kind of magic elixir they were drinking, but somehow those guys managed to nail it from day one.

Simpler does not mean better. ed(1) is definitely simpler than any text editor out there. DOS is simpler than any modern OS out there. Yet we use none of these because complexity is needed for sophistication.

>Simpler does not mean better.

Doesn't mean worse either. If it solves the same problem as dep in a less complex way I'd say it's better, if it actually does is something we'll see once it sees adoption.

> Look at NPM and Yarn; they're still struggling to get all the details right.

I think that's a bit unfair. NPM has been a horrible package manager in a multitude of ways since day 1. My default assumption if it gets something wrong it isn't because it's hard, but because npm gets a lot of things wrong.

Yes, RubyGems got it right, but so did Composer. And Cargo. And every other language specific dependency manager I've used in over a decade. The lesson I'm drawing isn't that dependency management is uniquely hard, it's that npm is uniquely bad. :)

Comparison to NPM is also unfair because of the rather unique community around it.

Putting NPM on a pedestal of badness is unfair. NuGet deserves to be right up there next to it, but also holding the bouquet and wearing the tiara and waving to the crowd

I'm having a hard time rectifying the "Ruby's Bundler"+"solved problem" axiom. Take my experience with Chef. It is Ruby. Berkshelf is supposed to solve cookbook versions, but you can use bundler around that. As a "not-a-ruby" guy, it is all a bit confusing actually. All I know is that Bundler and Berkshelf have caused me untold issues. Never resolving dependencies that leads to manually finding what version update broke what. When I heard about using the Minimum Version Solver, my first thought was how that would have saved me so much time during my Cookbook Version wars.

I've not used Berkshelf, but I suspect your problems were related to Chef and the fact that they've built their own dependency system that also interacts with Bundler/RubyGems.

Anecdotally, my company has used Ruby since around 2004, and Bundler since its first release, and we never had any issues. That doesn't mean nobody has ever had any issues (clearly! [2]), but it generally seems like Ruby package management is a solved problem, and that it would be a good model for any dependency system to use.

Bundler does have one feature (or misfeature) that Russ Cox criticizes: "bundle install some_gem" can cause unrelated gems' minor (or maybe it's minor) versions to be upgraded even if you don't tell it to. I've never liked that, and would much prefer to use "bundler update" to perform explicit upgrades. But I don't think that behaviour is at all tied to its solver, or that MVS is needed to fix it.

[1] https://github.com/bundler/bundler/issues/5068

[2] https://github.com/bundler/bundler/issues

It seems a little unusual for Go because they've generally gone with a good, simple, and well-proven model for things. That's sort of the whole appeal: the good kind of boring. I don't really see the point of the bikeshedding they're engaged in now, and they've made the upgrade path for everyone who's been working under dep, and glide before that, more difficult than it needs to be. The rationale behind it isn't really very solid IMO either. But I suppose I am just a mere mortal, so how I could I possibly understand?

The upgrade path for dep users is actually pretty easy and they aren't done yet. Vgo will read your dep lock file if it is present and use it to build its own lock file.

There are some warts here and there but again, it isn't even out yet and it still works pretty well. I feel like most of the complaints are coming from people who haven't actually give it a go. (pun intended)

Russ Cox has also been very responsive with tracking down those problems that do crop up and addressing them quickly. The only really big pain point is if you have a dependency which is > v1 and therefore requires new import paths. You can get around that with virtual versions but that's where the main pain point is.

But ironically that isn't at all the bit people are having issues with vgo about. (rather its insistence on MVS)

vgo is exactly in the spirit of Go: they took a popular mechanism and simplified it.

vgo works 90% like other systems with one major simplification: it replaces a complicated system of declaring version dependencies which requires SAT solvers to implement with a much simpler, predictable algorithm that they believe will work just as well in practice.

As a bonus it also removes the need for lock files, which is what other systems require to fix the issue caused by SAT solver (chosen versions of dependencies are unpredictable and will change if dependencies have newer versions).

As it is with engineering, the new method also has drawbacks, which is partly why the issue is so hotly debated.

As it is with Go, they believe the advantages of simplicity out weight the drawbacks.

We'll have to wait and see until it's implemented and used to really decide. So far Go's strong focus on simplicity served the language pretty well.

Note that none of the vgo precursors (or currently vgo itself) have been official Go tools. dep, for example, is an experiment.

Tools have certainly existed, sure. And they continue to exist. But they have not been official Go tools.

The irony is that dep was an implementation of a widely used and well tested pattern, and that vgo is essentially a new paradigm which has been accepted after just a proposal rather than a full-blown experiment.

This particular problem has been obvious since Go was first open sourced, and the way the solution is being managed is a pain in the ass.

I don’t disagree on any particular point. From a community-oriented perspective it seems odd to me as well, but I’m completely unqualified to critique the proposal on its technical merits.

All I can say is A) I hope it’s a good technical approach and B) I hope it doesn’t result in some kind of massive chasm.

> but I’m completely unqualified to critique the proposal on its technical merits.

If you ever used a working, solid package manager, you're qualified to critique. I've used many languages and their respective package managers, they just worked and got out of my way, even if I used the language to just write a hello world and see what libraries are available. With Go however, there always is a Schrodinger's package manager that is always on there like some reality show, and when you observe it finally, what do you see? Something some guy likes better than what the community was nearly deciding to universally adopt. All these shenanigans are off-putting. Especially when the blinking problem is fetching some tarballs and extracting files out of them after maybe checking checksums. CPAN's been doing that since the good part of the 90's.

Reply on news.ycombinator.com