Hacker News Reader

Comment by jrs95 | Hacker News Reader

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?

View on HN

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.

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)

Reply on news.ycombinator.com