6 ms·

Try was rejected and modules are awesome in my opinion. Easily the best dependency management I’ve worked with, across Ruby (Gems), Python (PIP), Java (Gradle/M

Try was rejected and modules are awesome in my opinion. Easily the best dependency management I’ve worked with, across Ruby (Gems), Python (PIP), Java (Gradle/Maven) etc. Up to this point, the ratio of useful enhancements to unnecessary cruft has heavily skewed towards usefulness. The post links to a new questionnaire the core wants all change proposers to answer - the questions are pretty good and force a bit of intense soul searching for everyone asking for a change. That will probably stifle ideas a bit, but resisting change by default is what we want out of this language anyway.

eberkund 7y ago
Those are all awful dependency management examples. I won't say Go dependency management is terrible, but it's certainly not awesome. At least to someone who has used PHP (Composer), Rust (Cargo), JavaScript (NPM), C# (NuGet).
- sa46 7y ago
  I don't think NPM is an example of a good dependency management system. It works, but it doesn't spark joy. Some issues I've run into: - npm install ignores package-lock.json and uses package.json. The work-around is to use npm ci. https://stackoverflow.com/a/45566871/30900 https://stackoverflow.com/a/45566871/30900 - Flakiness. An acceptable solution to npm difficulties is `rm -rf node_modules; npm i`. Admittedly, this has improved a lot in recent years. NPM also inherits the design preferences of the JS ecosystem. - Simple packages have deep dependency graphs. - Functionality is spread across multiple packages, sometimes at a granularity of a function per package. - If you want types, you roughly double the number of packages you need.
  - thrwaway69 7y ago
    Half the issues you mentioned are due to the ecosystem/community (one liner packages and deep dependency isn't fault of npm but it might be an unintentional result of how easy it was/is to publish and reuse packages) and the other half I don't notice by using yarn/pnpm. Getting types is optional and only required if you use typescript which you don't have to. It does improve the editor experience for vanilla js but those are put under dev dependency. There are a lot of things that can be improved though. Lot of packages put their config inside package.json which is honestly messy. The whole script part is a bit restricting. Better approach would have been to follow how mix (elixir) does it. Json is limiting as a format, no comments. Like you mentioned, it inherits the mentality of js ecosystem. It doesn't feel part of node but a separate piece of its own.
- sosodev 7y ago
  Why are gems awful? It’s one of the best imo
  - sudhirj 7y ago
    Gems are fine-ish... they rubygems infrastructure is really slow, though. Maybe github packages will be better. And the ton or native code compilation sucks a bit, especially when compared to Go. CGO isn’t all roses, but it’s still a bit less common because you can get comparable performance with pure Go.
- jayd16 7y ago
  Why is gradle/maven significantly different than Nuget as far as dependency management goes? The only major difference is Gradle and Maven also handle a lot of the build management as well.
simiones 7y ago
I was curious - what's wrong with Maven that is improved in Go modules? I personally found Maven much more friendly, since there are no odd interactions with your source-control solution, you get all relevant details in the Maven pom.xml. I also find this idea of relying on semver, especially with Go's insistence on renaming packages for major version changes, to be very unpleasant and brittle, especially for internal packages.
- tikkabhuna 7y ago
  One idea I like is to be able to depend on a branch. In Java it would be nice to depend on a branch, rather than dealing with snapshots. Obviously that comes at the cost of coupling with the VCS. Maybe its not worth it. Interesting idea though.
  - LadyCailin 7y ago
    The idea of a “branch” is not particularly novel, and I think any useful VCS will have an equivalence. I’d be perfectly fine with relying on that as much as I do any other aspect of a package manager.
  - simiones 7y ago
    Isn't that much harder to do with Go mod than with Maven? With Maven, you can define your own versioning scheme and easily include the branch as a component of the version "number". In Go mod, as far as I can tell, you have to have a Semver vMAJOR.MINOR.PATCH version, which is much more difficult to adjust for short-lived branches.
- sudhirj 7y ago
  Each library needs to be build a JAR, which isn't the case in Go - in Go you just put in the code URL (git repo / branch / sha1) and you have it. Also locks the dependency to that sha1, and crypto verifies it. So you get all the benefits of building an artefact, hash verification and central repo without having to do any of the work.
  - 7y ago

eberkund 7y ago

Those are all awful dependency management examples. I won't say Go dependency management is terrible, but it's certainly not awesome. At least to someone who has used PHP (Composer), Rust (Cargo), JavaScript (NPM), C# (NuGet).

sa46 7y ago
I don't think NPM is an example of a good dependency management system. It works, but it doesn't spark joy. Some issues I've run into: - npm install ignores package-lock.json and uses package.json. The work-around is to use npm ci. https://stackoverflow.com/a/45566871/30900 https://stackoverflow.com/a/45566871/30900 - Flakiness. An acceptable solution to npm difficulties is `rm -rf node_modules; npm i`. Admittedly, this has improved a lot in recent years. NPM also inherits the design preferences of the JS ecosystem. - Simple packages have deep dependency graphs. - Functionality is spread across multiple packages, sometimes at a granularity of a function per package. - If you want types, you roughly double the number of packages you need.
- thrwaway69 7y ago
  Half the issues you mentioned are due to the ecosystem/community (one liner packages and deep dependency isn't fault of npm but it might be an unintentional result of how easy it was/is to publish and reuse packages) and the other half I don't notice by using yarn/pnpm. Getting types is optional and only required if you use typescript which you don't have to. It does improve the editor experience for vanilla js but those are put under dev dependency. There are a lot of things that can be improved though. Lot of packages put their config inside package.json which is honestly messy. The whole script part is a bit restricting. Better approach would have been to follow how mix (elixir) does it. Json is limiting as a format, no comments. Like you mentioned, it inherits the mentality of js ecosystem. It doesn't feel part of node but a separate piece of its own.
sosodev 7y ago
Why are gems awful? It’s one of the best imo
- sudhirj 7y ago
  Gems are fine-ish... they rubygems infrastructure is really slow, though. Maybe github packages will be better. And the ton or native code compilation sucks a bit, especially when compared to Go. CGO isn’t all roses, but it’s still a bit less common because you can get comparable performance with pure Go.
jayd16 7y ago
Why is gradle/maven significantly different than Nuget as far as dependency management goes? The only major difference is Gradle and Maven also handle a lot of the build management as well.

simiones 7y ago

I was curious - what's wrong with Maven that is improved in Go modules? I personally found Maven much more friendly, since there are no odd interactions with your source-control solution, you get all relevant details in the Maven pom.xml. I also find this idea of relying on semver, especially with Go's insistence on renaming packages for major version changes, to be very unpleasant and brittle, especially for internal packages.

tikkabhuna 7y ago
One idea I like is to be able to depend on a branch. In Java it would be nice to depend on a branch, rather than dealing with snapshots. Obviously that comes at the cost of coupling with the VCS. Maybe its not worth it. Interesting idea though.
- LadyCailin 7y ago
  The idea of a “branch” is not particularly novel, and I think any useful VCS will have an equivalence. I’d be perfectly fine with relying on that as much as I do any other aspect of a package manager.
- simiones 7y ago
  Isn't that much harder to do with Go mod than with Maven? With Maven, you can define your own versioning scheme and easily include the branch as a component of the version "number". In Go mod, as far as I can tell, you have to have a Semver vMAJOR.MINOR.PATCH version, which is much more difficult to adjust for short-lived branches.
sudhirj 7y ago
Each library needs to be build a JAR, which isn't the case in Go - in Go you just put in the code URL (git repo / branch / sha1) and you have it. Also locks the dependency to that sha1, and crypto verifies it. So you get all the benefits of building an artefact, hash verification and central repo without having to do any of the work.
- 7y ago