Hacker News Reader

> But they have, multiple times? First it was just giving people links to godep when people complained in github issues. Then it was a tacit "we like this" about gps and glide. Then it was a pretty-much-official-blessing of dep. Now it's a super-official-now-we-mean-it implementation of vgo. I recognize this as a pattern because I do it all the time, software engineers constantly re-write things from the ground up when they don't care about actually solving the problem and just want to play around with cool new ideas.

No. Golang hasn't had an official/pretty-much-official dependency management system. The community recommends some tools over others, but that's about it.

With dep it is a bit different - the creators were google engineeers and they wanted it to become the official tool, with integration as a go subcommand etc.pp. - but that was never signed off by Pike or any other lead, only confirmed that it would be a possibility if the tools performs well.

With vgo its similar to dep - a proof of concept to see _if_ it works nicely.

Regarding a library multiple tools can use; Yes, that would be a nice thing - however when designing such a tool _and_ a library at the same time you will get into bigger problems. Generally you'll want a library designed by someone who already solved a given problem in at least one way. That brings enough experience to make the correct architectural decisions early on as well as a good, usable API.

I'm happy that we don't just get half-assed solutions just to have one. I have seen enough projects go to shit because a major step in the project was reconsidered a few times before management put a lock on it because it went through 'enough' revisions.

>"With dep it is a bit different - the creators were google engineeers and they wanted it to become the official tool, with integration as a go subcommand etc.pp. - but that was never signed off by Pike or any other lead, only confirmed that it would be a possibility if the tools performs well."

I'm frustrated. I started using Go during version 0.8 and have been using it since with no dependency mgmt beside my own forks because I hated everything I tried. Then dep comes along, I give it a few months to mature, try it, and it worked great. It solves my common use cases near perfectly.

What this blog post and proposal lacks IMHO is a clear case for why dep isn't "good enough". All I see is handwaving:

"Early on, we talked about Dep simply becoming go dep, serving as the prototype of go command integration. However, the more I examined the details of the Bundler/Cargo/Dep approach and what they would mean for Go, especially built into the go command, a few of the details seemed less and less a good fit."

So "a few of the details seemed less and less a good fit" is a statement that is impossible to refute because it is too scare on any details.

This.

You want feedback now, on this new proposal?

Why bother?

It's patently obvious that our feedback on dep has been totally ignored.

What indication is there anyone will pay attention to any feedback now?

I can't be bothered any more.

I just want one solution to be picked, blessed, implemented and then not changed five minutes/months later.

There's many pages here that explain in detail the problem with the existing solutions. Read all of them. https://research.swtch.com/vgo

If you read the minimal version selection algorithm, it's clear that the proposed solution solves the problem in a novel way.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

In my eyes, it would be a warning sign, if the new proposal contained too much completely new ideas. That would mean, that they are not tested in practise. That is why we needed all those project which implemented versioning so far. But getting to an officially blessed, many years supported proposal, starting with a clean sheet, but based on all the experienced lerned, is a good approach.

Welcome to IT as a career.

Having started in the 90s, I have been through these same conversations regarding Adobe, Oracle (oh lawd Oracle) MS, Dell, Apple to a lesser extent.

“Vendor the industry currently relies on heavily is changing things or yanking the rug again?”

The free market works by big players yanking every one else around. Guh.

The big players aren't yanking anyone around. They take responsibility by announcing things like alpha periods, beta periods, release candidates, Long Term Stability branches, etc. And enterprise developers take advantage of these, ensuring that they only code production applications against stable/LTS libraries and APIs.

It's SMB/"indie" developers who should be taking the responsibility here, I think, for relying on these officially-unstable packages in their own production systems, and especially for encouraging others to rely on such. Yes, sometimes, it's the only way to be competitive/have a https://en.wikipedia.org/wiki/Unique_selling_proposition. But that doesn't mean that it isn't their responsibility to cope with these changes. They're taking on that risk-of-change by using those unstable libraries or APIs.

Heck, this is half of the point of software Venture Capital: being able to underwrite the risk of relying on an unstable platform/ecosystem, so that you can have enough runway to recover and still finish your product if "the ground moves under you", and therefore can "safely" rely on these unstable technologies.

(And one not-oft-talked-about property of bootstrapped startups is that they have to underwrite that risk themselves. If a bootstrapped startup isn't just gambling with its founders' money, it has to behave more like an enterprise development shop, building on only stable foundations.)

Theoretically, you could move this underwriting role into the companies themselves, such that the companies themselves would monetarily cushion the blow of changes in their unstable APIs. But they'd need a pretty big interest in the involved consumers to do so. In such a world, you likely wouldn't have separate startup businesses using the BigCorps' unstable APIs; rather, you'd have a set of BigCorp incubators with large shares in most new startups. Maybe that hypothetical world would have higher https://en.wikipedia.org/wiki/Gross_world_product than our own! But I bet there'd be fewer startups, because starting a startup would be a lot more like a regular BigCorp job.

My experience IBM products like websphere tell different story. The were slow and buggy and never slow and solid.

There's no comparing proprietary products with open source projects. The Go project is a beautiful body of work and there's no call for comparing it to proprietary crapware.