5 ms·

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

by aikah 10y ago

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.

BarkMore 10y ago
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.
0xmohit 10y ago
> 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 https://golang.org/doc/go1compat
- yiyus 10y ago
  > And Go 1 compatibility promise [0] would prevent any change. For example? I cannot see how the language itself could be the problem here.
- BarkMore 10y ago
  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 https://golang.org/doc/go1compat#tools).
maerF0x0 10y ago
> 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.
- nyan4 10y ago
  ...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.
  - zwily 10y ago
    This has more to do with the lack of dynamic linking than vendoring.
    - nyan4 10y ago
      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.
  - skybrian 10y ago
    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.
- 10y ago
0xdeadbeefbabe 10y ago
Not sure how it is a complete mess, maybe a small mess. Who is reinventing wheels anyway?
Thaxll 10y ago
"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?
paulsmith 10y ago
> Go ecosystem is a complete mess. And yet, people manage to get work done in it.
deleted 10y ago
[deleted]

by aikah 10y ago

BarkMore 10y ago

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.

0xmohit 10y ago

> 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 https://golang.org/doc/go1compat

yiyus 10y ago
> And Go 1 compatibility promise [0] would prevent any change. For example? I cannot see how the language itself could be the problem here.
BarkMore 10y ago
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 https://golang.org/doc/go1compat#tools).

maerF0x0 10y ago

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

nyan4 10y ago
...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.
- zwily 10y ago
  This has more to do with the lack of dynamic linking than vendoring.
  - nyan4 10y ago
    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.
- skybrian 10y ago
  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.
10y ago

0xdeadbeefbabe 10y ago

Not sure how it is a complete mess, maybe a small mess. Who is reinventing wheels anyway?

Thaxll 10y ago

"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?

paulsmith 10y ago

> Go ecosystem is a complete mess. And yet, people manage to get work done in it.

deleted 10y ago

[deleted]