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

61–69 of 69 posts

Re: An Analysis of vgo

#61

Post by Karrot_Kream »

skywhopper wrote: post #35
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…

From what I read `dep` isn't deprecated, and is right now the recommended way to track dependencies. I used `dep` in a project I started a bit ago (around the time of the announcement of `vgo`) and it's been working out just great.

That said I agree it's super frustrating, and the vgo announcement just had zero finesse. This isn't a language of experimenters hacking away, there are large production systems that run on solely Go code. Upending the main tool (`go` itself) and the versioning strategy is not to be taken lightly.

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

Here I disagree. Rust is fine for small utilities right now, but if you start building larger apps, developing with futures, tokio, and some of the other async libraries is a nightmare. The APIs are moving really quickly (`futures` hit 0.2, `tokio` is on 0.1 so I don't blame them really) and the ecosystem is still extremely immature. I'm excited for Rust, but it's not yet at the point that I want to build a complex application.

Re: An Analysis of vgo

#62

Post by deong »

zaphar wrote: post #41
TheDong wrote: post #19

Earlier quoted context omitted.

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

Mercurial was pretty close to contemporaneus. And when git was first launched it was extremely bare bones and even more incredibly hard to use than it is now. Darcs, Monotone, and Arch were slower and I think predated git. Darcs in particular blew the doors off of git as far as ease of use given the problem domain. Git won almost entirely due to two factors. 1. The linux kernel used it so that brought some prestige.…

It's also important to remember just how far Git was ahead of most competitors in performance. I was using monotone quite a bit around this time, and while its UI was frankly not much better than git's, it at least worked acceptably quickly. Darcs was mostly defined in the public eye by the exponential merge issue. Hg was fine, for some definition of fine, but it was enough slower than git to be annoying -- maybe not deal-breaking, but noticeable on pretty much any task.

I remember installing cogito to act as a front-end for git because very early on it seemed obvious that (a) git was going to win, and (b) it was going to win in spite of its UI, which was saying something.

Re: An Analysis of vgo

#63

Post by Groxx »

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…

This is essentially what shrinkwrap does. Apparently it has issues, but it's designed to be the lock file for your package.json.

Re: An Analysis of vgo

#64

Post by gkya »

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…

WRT modules, that seems like very confusing terminology. It seems to me that vgo calls what all others call packages moduels, and the fact that module is a really overloaded term does not help.

Re: An Analysis of vgo

#65

Post by lobster_johnson »

gkya wrote: post #64
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…

WRT modules, that seems like very confusing terminology. It seems to me that vgo calls what all others call packages moduels, and the fact that module is a really overloaded term does not help.

Go already has "packages", so it's not something that can be used for what vgo calls modules.

A Go package is similar to a Java or Python package; it's just a namespace. A vgo module can be thought of as a collection of packages that have a version number and a single canonical name.

I don't find the terms particularly confusing, given that Go doesn't already have anything called a module. It would really only be confusing if you're deep into another language that has "packages" and "modules". I personally don't find it difficult to context switch like that.

Re: An Analysis of vgo

#66

Post by gkya »

lobster_johnson wrote: post #65
gkya wrote: post #64

Earlier quoted context omitted.

WRT modules, that seems like very confusing terminology. It seems to me that vgo calls what all others call packages moduels, and the fact that module is a really overloaded term does not help.

Go already has "packages", so it's not something that can be used for what vgo calls modules. A Go package is similar to a Java or Python package; it's just a namespace. A vgo module can be thought of as a collection of packages that have a version number and a single canonical name. I don't find the terms particularly confusing, given that Go doesn't already have anything called a module. It would really only be con…

AFAIK for many languages a module is a unit of source code, e.g. a .py file for Python, and many modules constitute a package. And many times C/C++ are criticised for not having "modules" and for people having to #include header files which need to be maintained as a redundant module interface for the .o files. In Haskell every file generally starts with "module ModName where", and again, many modules make up a package.

Certainly it's not that big of a confusion, but still will probably be one in discussions, especially for polyglot programmers.

Re: An Analysis of vgo

#67

Post by glasser »

zaphar wrote: post #41
TheDong wrote: post #19

Earlier quoted context omitted.

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

Mercurial was pretty close to contemporaneus. And when git was first launched it was extremely bare bones and even more incredibly hard to use than it is now. Darcs, Monotone, and Arch were slower and I think predated git. Darcs in particular blew the doors off of git as far as ease of use given the problem domain. Git won almost entirely due to two factors. 1. The linux kernel used it so that brought some prestige.…

Darcs was easy to use? Are you referring to the same darcs whose manual tried to explain concepts by making analogies to the simpler and better-understood theory of quantum mechanics?

Re: An Analysis of vgo

#68

Post by irishsultan »

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…

> Each "npm install" will ignore any lock file your package was using during development.

That's true for npm, but not for bundler (luckily).

Re: An Analysis of vgo

#69

Post by bennofs »

munificent wrote: post #57
red_admiral wrote: post #12

> If there are two algorithms that satisfy the same requirements, and only one is NP-complete, you pick the other one. Problems can be NP-complete. Algorithms cannot - they can be exponential time (and if your choice is between exponential and double exponential, you pick the former!) In practice, and especially for SAT solving, as far as I understand the state of the art is that the general case is NP-hard but we ha…

> In practice, and especially for SAT solving, as far as I understand the state of the art is that the general case is NP-hard but we have tools that work surprisingly well in those cases that reality tends to produce. You're correct. Modern version solvers need fairly sophisticated algorithms, but it's not rocket science. It's mostly a non-problem for most users of most package managers most of the time.

The thing that worries me about this line of thinking is that as far as I know, we don't know much about why SAT solvers tend to work well in practice. So if I ever happen to hit a problem that the solver cannot solve, all we can say is "well bad luck". If the algorithm fails, I won't have any way to know why. This strikes me as a bad situation to be in.
Post reply on HN