3 ms·

> impact on core features of a language platform, like package management In this specific case (which is important to the discussion) there effectively was n

> impact on core features of a language platform, like package management In this specific case (which is important to the discussion) there effectively was nothing you could call "management" in what the core tooling provided for resolving and fetching dependencies. I think the reason it wasn't there, was because that wasn't very important to Google which famously operates a company-wide mono repo. Dependency management wasn't a problem Google had, so an official solution was a very long time coming, and left the interim solution providers feeling quite raw.

tptacek 7y ago
"There effectively was nothing you could call 'management'" is hyperbole. I know what you mean: you don't like the way they managed it. Ok. But this is a pretty good illustration of how there's no winning for the Go core team in responding to this stuff.
- jeremyjh 7y ago
  I honestly don't think its hyperbole. What we had with go get, would install different versions of dependencies each time you checked out your repository and built it. That isn't managed. Managed is what they recommended you to do, which is vendor all the dependencies, but that isn't something provided by the go tooling.
  - walterstucco 7y ago
    Honestly, that's a community problem. If the code is guaranteed to work with the current version of the dependency and packages were built to not break their API, there would be no problem I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
    - kybernetikos 7y ago
      > packages were built to not break their API That's a lovely sentiment, but it doesn't help much when you've got no consistency between checkouts and builds are failing because of upstream changes that the code you're trying to work with doesn't even know it's using, and to try to fix an issue first requires you to spend days dealing with bitrot. Here are some principles: 1. only the team working on a component should be able to break the build of that component. 2. Components should not break outside of commits. The truth is, that your 'API' ends up being every part of your behavior that is relied on by your dependents and their dependents, ad infinitum, and it's almost impossible to make improvements without breaking such an API. Sometimes bugs are part of your de facto API. It's one thing to say 'people shouldn't depend on these features, look it even says so in the doc', but should and shouldn't are moral judgements, what is and what is not are the distinctions that drive whether your development and release process are fit for purpose. > I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves Well, there can be debate on the volume of problems on either side, but some other ecosystems attack this with tooling that can automate the process of getting notified that there's an upstream change, rebuilding with the new version, running the automated tests, and making it super easy to accept a commit updating the dependencies if the tests all work.
    - 0815test 7y ago
      > I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves Semver addresses this. You stick with a specific major version (or minor version for a 0.x release, where "minor" version changes can in fact introduce major breaks), and your dependency tool enforces this. However, it does still warn you if a newer version is available, so that you can start depending on it. (Of course, switching to a newer release is easier said than done if other modules might still depend on the previous one, and your build tool doesn't support the concurrent use of both in the same build!) This is essentially a solved problem.
      - drchickensalad 7y ago
        I think it's disingenouous to call this a solved problem. Regardless of their appearance, very few projects actually follow this consistently, because it's a lot of work and almost impossible to be sure.
- masukomi 7y ago
  I'm with @jeremyjh on this one. There was no management. There was a "fuck it. works for me." kind-of half-assed implementation that was frankly terrible when compared to ANY of its contemporaries. It spawned a ton of competing "package managers" that attempted to do a better job but none of them "won" (probably because none were officially sanctioned) so you ended up dealing with like six of them in order to manage the dependencies of whatever random project you tried to work with. No-one "managed" the problem. They just sat and watch the community flail around for years.
  - walterstucco 7y ago
    That's exactly what happens when a tool is left open to community If the community cannot agree on a simple thing like the package manager, imagine what'll happen if it was in charge of evolving the language
    - rightbyte 7y ago
      That what's happen if the community has no say in what package manager is used or how it works and the community is not forced to use the official one and the community is not organized properly.
    - Lazare 7y ago
      I would say it's what happens when a community is explicitly not allowed to solve a problem. PHP, for all its warts, is 1) very community driven and 2) solved their package management problems via the community (with Composer). Go was not allowed to do that, because everyone knew that any solution had to be blessed by Google.

tptacek 7y ago

"There effectively was nothing you could call 'management'" is hyperbole. I know what you mean: you don't like the way they managed it. Ok. But this is a pretty good illustration of how there's no winning for the Go core team in responding to this stuff.

jeremyjh 7y ago
I honestly don't think its hyperbole. What we had with go get, would install different versions of dependencies each time you checked out your repository and built it. That isn't managed. Managed is what they recommended you to do, which is vendor all the dependencies, but that isn't something provided by the go tooling.
- walterstucco 7y ago
  Honestly, that's a community problem. If the code is guaranteed to work with the current version of the dependency and packages were built to not break their API, there would be no problem I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves
  - kybernetikos 7y ago
    > packages were built to not break their API That's a lovely sentiment, but it doesn't help much when you've got no consistency between checkouts and builds are failing because of upstream changes that the code you're trying to work with doesn't even know it's using, and to try to fix an issue first requires you to spend days dealing with bitrot. Here are some principles: 1. only the team working on a component should be able to break the build of that component. 2. Components should not break outside of commits. The truth is, that your 'API' ends up being every part of your behavior that is relied on by your dependents and their dependents, ad infinitum, and it's almost impossible to make improvements without breaking such an API. Sometimes bugs are part of your de facto API. It's one thing to say 'people shouldn't depend on these features, look it even says so in the doc', but should and shouldn't are moral judgements, what is and what is not are the distinctions that drive whether your development and release process are fit for purpose. > I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves Well, there can be debate on the volume of problems on either side, but some other ecosystems attack this with tooling that can automate the process of getting notified that there's an upstream change, rebuilding with the new version, running the automated tests, and making it super easy to accept a commit updating the dependencies if the tests all work.
  - 0815test 7y ago
    > I disagree with the idea that sticking with a specific version of a dependency is a good solution, it creates more problems than it solves Semver addresses this. You stick with a specific major version (or minor version for a 0.x release, where "minor" version changes can in fact introduce major breaks), and your dependency tool enforces this. However, it does still warn you if a newer version is available, so that you can start depending on it. (Of course, switching to a newer release is easier said than done if other modules might still depend on the previous one, and your build tool doesn't support the concurrent use of both in the same build!) This is essentially a solved problem.
    - drchickensalad 7y ago
      I think it's disingenouous to call this a solved problem. Regardless of their appearance, very few projects actually follow this consistently, because it's a lot of work and almost impossible to be sure.
masukomi 7y ago
I'm with @jeremyjh on this one. There was no management. There was a "fuck it. works for me." kind-of half-assed implementation that was frankly terrible when compared to ANY of its contemporaries. It spawned a ton of competing "package managers" that attempted to do a better job but none of them "won" (probably because none were officially sanctioned) so you ended up dealing with like six of them in order to manage the dependencies of whatever random project you tried to work with. No-one "managed" the problem. They just sat and watch the community flail around for years.
- walterstucco 7y ago
  That's exactly what happens when a tool is left open to community If the community cannot agree on a simple thing like the package manager, imagine what'll happen if it was in charge of evolving the language
  - rightbyte 7y ago
    That what's happen if the community has no say in what package manager is used or how it works and the community is not forced to use the official one and the community is not organized properly.
  - Lazare 7y ago
    I would say it's what happens when a community is explicitly not allowed to solve a problem. PHP, for all its warts, is 1) very community driven and 2) solved their package management problems via the community (with Composer). Go was not allowed to do that, because everyone knew that any solution had to be blessed by Google.