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

31–40 of 69 posts

Re: An Analysis of vgo

#31

Post by ngrilly »

cdoxsey wrote: post #29
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.

Honestly, Russ Cox published his first post about vgo on February 20 (https://research.swtch.com/vgo). It's been almost 3 months then. It's not fair to ask the community to wait any longer. If Sam Boyer has good reasons to oppose vgo, then he should publish them now.

Re: An Analysis of vgo

#32

Post by sagichmal »

ngrilly wrote: post #31
cdoxsey wrote: post #29

Earlier quoted context omitted.

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

Honestly, Russ Cox published his first post about vgo on February 20 ( https://research.swtch.com/vgo ). It's been almost 3 months then. It's not fair to ask the community to wait any longer. If Sam Boyer has good reasons to oppose vgo, then he should publish them now.

Russ waited over a year and a half before engaging meaningfully with the community on package management, and waited another nine months before coming up with this greenfield proposal. There's no reason to rush things now.

Re: An Analysis of vgo

#33

Post by pknopf »

endymi0n wrote: post #28
lobster_johnson wrote: post #9

Earlier quoted context omitted.

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

> using npm or bundler simply feels sane

I feel the opposite. Lock files are awesome when your developing a package, but after you release it, you are at the mercy of all your dependencies in making sure that they don't break semvar. Each "npm install" will ignore any lock file your package was using during development.

It would be awesome if I could distribute a package-json.lock file with my npm package and have yarn/npm use it when resolving packages on fresh installations.

Yeah, this would mean that there may be duplicated libraries in your node_modules tree, each with a slightly different version, even if semver compat. However, people break semver to often anyway.

I want to deploy a package to npm and be sure that it will never break, ever.

Re: An Analysis of vgo

#34

Post by paulsutter »

kasey_junk wrote: post #26
paulsutter wrote: post #24

Earlier quoted context omitted.

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.

Great then you should be able to do even better, right?

Seriously give it a try

Re: An Analysis of vgo

#35

Post by skywhopper »

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…

Yes! Speaking as a sysadmin who writes Go tools from time to time along with a lot of Bash, Ruby, etc, I’m no expert in the land of Go. But in terms of designing my code to be shareable and figuring out how to integrate it with other source code I deal with every day is a mess. dep had seemed a very promising direction, and so I’m really frustrated to see it’s been deprecated and we are still seemingly years out from a solution which may not even work well in the end. Quite honestly the situation is actively holding back Go, as it’s very hard to convince developers used to lock files and well defined packaging to build anything in a language with no official story on this, even after a decade. Go is rapidly losing the momentum it had for a while now that Rust is starting to become a more stable target and given Go’s inability to address package versioning.

Re: An Analysis of vgo

#36

Post by reificator »

sagichmal wrote: post #32
ngrilly wrote: post #31

Earlier quoted context omitted.

Honestly, Russ Cox published his first post about vgo on February 20 ( https://research.swtch.com/vgo ). It's been almost 3 months then. It's not fair to ask the community to wait any longer. If Sam Boyer has good reasons to oppose vgo, then he should publish them now.

Russ waited over a year and a half before engaging meaningfully with the community on package management, and waited another nine months before coming up with this greenfield proposal. There's no reason to rush things now.

> There's no reason to rush things now.

Golang is hurting right now because of this issue. In fact this and the lack of a canonical GUI approach are the only two caveats I have when suggesting the use of Go.

I'm not saying to rush, but the constant churn in this space needs to end as soon as it can. For a language with as much of a focus on simplicity and stability as Go, it's embarrassing that this has been an issue for so long.

I have been using Go professionally[0] starting sometime between 1.1 and 1.4 and in that time I have something like 4-5 different ways of handling dependencies in my repositories based on when those projects were started and/or last overhauled. Each time I changed my approach I was following the current best practices, or so I believed. It's madness, and it has to end sometime.

[0]: Started playing with it in 2009, in fun projects I'll use whatever works and/or is fun and/or gets the job done soonest. In professional projects I'm much slower to adopt new tools.

Re: An Analysis of vgo

#37

Post by regularfry »

pknopf wrote: post #33
endymi0n wrote: post #28

Earlier quoted context omitted.

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

> using npm or bundler simply feels sane I feel the opposite. Lock files are awesome when your developing a package, but after you release it, you are at the mercy of all your dependencies in making sure that they don't break semvar. Each "npm install" will ignore any lock file your package was using during development. It would be awesome if I could distribute a package-json.lock file with my npm package and have ya…

Can't you do this right now by specifying exact dependency versions in package.json? Lock files should be for applications, not libraries.

Re: An Analysis of vgo

#38

Post by ngrilly »

sagichmal wrote: post #32
ngrilly wrote: post #31

Earlier quoted context omitted.

Honestly, Russ Cox published his first post about vgo on February 20 ( https://research.swtch.com/vgo ). It's been almost 3 months then. It's not fair to ask the community to wait any longer. If Sam Boyer has good reasons to oppose vgo, then he should publish them now.

Russ waited over a year and a half before engaging meaningfully with the community on package management, and waited another nine months before coming up with this greenfield proposal. There's no reason to rush things now.

> There's no reason to rush things now.

I disagree. I want things to move forward as soon as possible. I've been waiting so long for a dependency management solution and for GOPATH deprecation!

Russ came with his "greenfield" proposal because he was not convinced that dep could become the long term solution to dependency management in Go.

Sam and the whole dep team have been working on package management for more than a year now. If they see important issues with vgo, I think they should be able to explain them succinctly in a post, at least to convince other gophers to hold on.

Re: An Analysis of vgo

#39

Post by pjmlp »

paulsutter wrote: post #34
kasey_junk wrote: post #26

Earlier quoted context omitted.

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.

Great then you should be able to do even better, right? Seriously give it a try

First we need to power up to Linus skill level, then we can apply the same community influence spells.

Git would be dead on the water if it wasn't for being written by Linus and a requirement to interact with Linux development.

Re: An Analysis of vgo

#40

Post by pknopf »

regularfry wrote: post #37
pknopf wrote: post #33

Earlier quoted context omitted.

> using npm or bundler simply feels sane I feel the opposite. Lock files are awesome when your developing a package, but after you release it, you are at the mercy of all your dependencies in making sure that they don't break semvar. Each "npm install" will ignore any lock file your package was using during development. It would be awesome if I could distribute a package-json.lock file with my npm package and have ya…

Can't you do this right now by specifying exact dependency versions in package.json? Lock files should be for applications, not libraries.

Yes, but "npm install" will by default add a semver-compat package version. The vast majority of packages out there use what "npm install" gives you be default.

Furthermore, even if I use exact versions in my package.json, that doesn't stop my referenced packages from internally referencing semver-compat versions.

At the very least, you should reference exact versions at the top level. It is better than nothing.

Post reply on HN