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

The vgo proposal is accepted. Now what?

research.swtch.com

Post reply on HN
Print view View original

111–120 of 138 posts

Re: The vgo proposal is accepted. Now what?

#111

Post by majewsky »

pcwalton wrote: post #50
lobster_johnson wrote: post #28

Earlier quoted context omitted.

Rust/Cargo had the luxury of being a greenfield project that could adopt semver from the beginning, whereas Go made the mistake of starting out, and then going years , without any official package management solution. As a result, Go has a swathe of applications and libraries that use specific workflows as well as a mélange of community-developed package management tools such as godep, Glide and dep. The semver stand…

Rust was actually around for a good while before Cargo was adopted. (In fact, there were two Cargos, the older of which bore very little resemblance to the Cargo of today.) Of course, Go was stable for longer. I have to admit I'm a bit confused as to why the dependency resolution algorithm in dep is seen as slow. The speed of the solver is not a problem in any other package management system I've seen. If it is indee…

> The speed of the solver is not a problem in any other package management system I've seen.

The package manager in YaST (Suse Linux's sysadmin tool) was notorious for its slow solver (and slow everything-else, for that matter) around 2006, when I started using Linux. It improved a lot in the openSUSE 11.x series around 2007/8 when they switched from a homegrown solver to a standard SAT solver package.

Re: The vgo proposal is accepted. Now what?

#112

Post by oceanswave »

skybrian wrote: post #58
lobster_johnson wrote: post #54

Earlier quoted context omitted.

Testing and package management aren't mutually exclusive. If you're in a monorepo, all your code evolves in lockstep. A core tenet of versioned package management is to get reproducible builds that only need to break once you choose to evolve forward in time (i.e. upgrade). Historically, most languages (C, C++, pre-Maven Java) haven't had package management at all, and so dependencies have typically been managed by v…

Yes, you are right. And I believe vgo is supposed to guarantee reproducible builds just like other package systems. However, when you upgrade a dependency, it's still possible that you're using a particular combination of library versions that have never been tested before. Some incompatibilities can be prevented by looking at version constraints. But you're not left with no error detection if the package system fail…

This methodology places way too much emphasis on the breadth of the tests into a test centric view— say you had a dep that had an SSL vulnerability - most of the time you’re not going to be checking for this type of thing at the level of your app, and doing so - but you bet you need to ensure that you are using the version of the dep that has the vulnerability fixed

Re: The vgo proposal is accepted. Now what?

#113

Post by sethammons »

pcwalton wrote: post #50
lobster_johnson wrote: post #28

Earlier quoted context omitted.

Rust/Cargo had the luxury of being a greenfield project that could adopt semver from the beginning, whereas Go made the mistake of starting out, and then going years , without any official package management solution. As a result, Go has a swathe of applications and libraries that use specific workflows as well as a mélange of community-developed package management tools such as godep, Glide and dep. The semver stand…

Rust was actually around for a good while before Cargo was adopted. (In fact, there were two Cargos, the older of which bore very little resemblance to the Cargo of today.) Of course, Go was stable for longer. I have to admit I'm a bit confused as to why the dependency resolution algorithm in dep is seen as slow. The speed of the solver is not a problem in any other package management system I've seen. If it is indee…

We use Chef (Ruby). Cookbook version solving has been a repeatedly painful experience, occasionally never finding a solution. When this happens, you get to manually dig around and find the culprit.

Re: The vgo proposal is accepted. Now what?

#114

Post by oceanswave »

Lazare wrote: post #91
lobster_johnson wrote: post #56

Earlier quoted context omitted.

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

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

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

Re: The vgo proposal is accepted. Now what?

#115

Post by oceanswave »

marcus_holmes wrote: post #108
eosrei wrote: post #41

Earlier quoted context omitted.

Nothing. Use dep now. In fact, since you are just starting out, see how far you can get using only the standard library. Later, there will be a seamless upgrade to vgo.

Seconded. Unlike Node/Ruby/most other modern languages, Go devs actively avoid including dependencies if at all possible. And contrary to rumour, this is not because Go's dependency management sucks. It's more about the pursuit of simplicity, and avoidance of magic. You can write pretty much anything using just the standard library (and some of the official packages, like the crypto ones). As the parent said, it's go…

So go is about recreating the wheel, over and over again

Re: The vgo proposal is accepted. Now what?

#116

Post by danharaj »

Avi-D-coder wrote: post #75

How does Haskell's cabal compare to vgo?

Cabal uses a SAT solver. It's in the middle of a beta for replacing it's global package management with per-project package management by default (so-called new-style builds). There were some warts in the past when it couldn't manage different versions of the same package, I think because of a ghc issue but that is in the past.

Most industrial users use stack or nix on top which reduce the use of Cabal's version solver.

Re: The vgo proposal is accepted. Now what?

#117

Post by sseth »

Lazare wrote: post #89
lobster_johnson wrote: post #37

Earlier quoted context omitted.

Cox discusses Cargo here, and why he doesn't like it: https://research.swtch.com/vgo-repro

> The lock file stops future upgrades; once it is written, your build stays on serde 1.0.27 even when 1.0.28 is released. In contrast, minimal version selection prefers the minimum allowed version, which is the exact version requested by some go.mod in the project. That answer does not change as new versions are added. So with Cargo, you get the exact version you want, ie 1.0.27, and it won't automatically update whe…

The key here is that Cargo ignores the lock files of the dependency, while vgo uses the go.mod files of the dependency.

So, if project A uses B, which uses 1.0.27 of C, then the lock file for A is locked to that version of C. Suppose B now releases a version that was tested with 1.0.28 of C, A will continue to be built with the older version because of the lock file, while vgo would (correctly) start using the new version because of MVS.

Re: The vgo proposal is accepted. Now what?

#118

Post by sethammons »

lobster_johnson wrote: post #56
_pfxa wrote: post #4

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

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

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.

Re: The vgo proposal is accepted. Now what?

#119

Post by sethammons »

oceanswave wrote: post #115
marcus_holmes wrote: post #108

Earlier quoted context omitted.

Seconded. Unlike Node/Ruby/most other modern languages, Go devs actively avoid including dependencies if at all possible. And contrary to rumour, this is not because Go's dependency management sucks. It's more about the pursuit of simplicity, and avoidance of magic. You can write pretty much anything using just the standard library (and some of the official packages, like the crypto ones). As the parent said, it's go…

So go is about recreating the wheel, over and over again

Not really. Generally, the wheel you need and the wheel I need are a bit different. Instead of using some bloated "all-wheel," developers choose their custom wheel.

Simple example, SyncMap. This is a general purpose all-wheel, and as such, due to Go's type system, you have to use runtime type assertions against it. If I need a lockable map, I just make one and it is of the type I need, say map[string]*Foo. I just wrap it in a struct with a lock and I'm done.

For more complicated things, most everyone will pull in a package. I'm not going to waste some time making a Redis or Kafka package. For a web server, I may pull in a different muxer, but only if needed.

Re: The vgo proposal is accepted. Now what?

#120

Post by amluto »

pcx wrote: post #64
pcwalton wrote: post #50

Earlier quoted context omitted.

Rust was actually around for a good while before Cargo was adopted. (In fact, there were two Cargos, the older of which bore very little resemblance to the Cargo of today.) Of course, Go was stable for longer. I have to admit I'm a bit confused as to why the dependency resolution algorithm in dep is seen as slow. The speed of the solver is not a problem in any other package management system I've seen. If it is indee…

> The speed of the solver is not a problem in any other package management system I've seen This! I've never heard anyone complain about this aspect of a package manager, EVER. vgo seems to be optimizing for a problem no one has.

I once waited for a long time for an older Haskell dependency solver to contemplate a situation before it gave up.
Post reply on HN