Hacker News Reader

Comment by aikah | Hacker News Reader

Go ecosystem is a complete mess. I understand what Go maintainers tried to do, but Go isn't like Gnome lib,or Linux core lib where dependencies are stable. And the "just vendor" stuff pushed by some Go pundits is stupid. Clutter or Gtk don't vendor Gdk or Glib. So Go right now is about everybody reinventing the wheel, because you can't write reproducible build with 3rd party packages thus create an ecosystem with Go get. The solution ? deprecate Go get in favor of a new tool that supports at least fetching tags for packages. Project based build Tools (like Gb) work for apps, they don't work for libraries. Glide and co have a big problem : everybody is using a different package manager that is incompatible with others.

The question isn't being solved yet because to solve it seriously it would require to change how the language works at first place.

View on HN

> And the "just vendor" stuff pushed by some Go pundits is stupid.

I see it as an excellent way to allow me to ensure that no matter what my project continues to build and work. And dont say "just pin a version" because there have been packages that lose or update their tags and break things, or the distribution channel (npmjs, github, w/e) go down and suddenly I am up a creek for a deploy/build.

When I vendor, I have what I need to build and deploy my code with a lot fewer points of failure.

...until the unfortunate end user that needs to run tenths of systems runs in a security issue. Then the admins cannot possibly learn how to fork, patch, rebuild, test, deploy in 20 different languages. And they cannot rely on security updates from Linux Distributions because they installed vendorized code blobs.

This has more to do with the lack of dynamic linking than vendoring.

The two are very connected. Yet, even with dynamic linking, the libraries could be always and only bundled with the application, and the application could be designed to work against the bundled versions and not even tested against other versions. On a practical level this makes it extremely expensive to perform updates.

Vendoring is what Linux distributions do. They also provide multi-language automatic builds, security updates and all the other things you mention.

So the problem is not vendoring itself. For a large organization like a Linux distribution, it's a valid technique. However, nobody is maintaining a distribution for the Go ecosystem, or at least not one that's publically available.

vendoring is a solution to the problem of reproducability, not the problem of distribution. Vendoring particularly for application code should be at least an optional part of whatever solution is chosen by the go team. Vendoring is not the only solution in this space, at $work we mirror any third party repository we use.

However, vendoring doesn't solve the problem of getting a library that I have reasonable guarantees will work with the rest of the ecosystem. You can use vendoring in libraries but you can only use their types internally in your apis, if you put them on the boundaries you will run into compatibility issues.

Most systems have package managers with versions and a central repo and dependency tracking.

Problems with fetching builds are rare but if you care package managers frequently have some not exactly recommended plugin to allow vendoring.

Plus with the package manager you can update the optionally vendored dependencies quickly.

Central repos are less likely to be deleted then github repos and some like Crates.io have a policy not to remove crates(or allow authors to remove crates) unless there are legal issues.

A better solution (then vendoring) for larger organizations that is also usually available in the form of mirroring or partial mirroring of the central repository(and pulling from that instead).

> The question isn't being solved yet because to solve it seriously it would require to change how the language works at first place.

And Go 1 compatibility promise [0] would prevent any change.

In theory, you could define a GOPATH to install custom packages. You install half a dozen or so packages, and it's not trivial to determine what all you installed. A Go update arrives. Now some of those packages fail to update. Either spend hours debugging, reporting bugs, or rm -rf $GOPATH and reinstall everything.

The language is wonderful in so many ways, but a number of seemingly silly things make it annoying.

[0] https://golang.org/doc/go1compat

> And Go 1 compatibility promise [0] would prevent any change.

For example? I cannot see how the language itself could be the problem here.

Any change will be in the tools, not the language. The compatibility promise explicitly states that the tools can change (https://golang.org/doc/go1compat#tools).

I understand that the tools will need to be changed, but what needs to be changed in the language? Because import paths are strings interpreted by the tools and not the language, there seems to be good separation between the language and issues of source code organization, packaging, etc.

"The question isn't being solved yet because to solve it seriously it would require to change how the language works at first place."

This doesn't make any sense. What problem are you talking about?

> Go ecosystem is a complete mess.

And yet, people manage to get work done in it.

Not sure how it is a complete mess, maybe a small mess.

Who is reinventing wheels anyway?

Reply on news.ycombinator.com