4 ms·

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 y

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.
- pjmlp 7y ago
  Actually I find it a disadvantage, I don't want to deal with source code from other teams/companies, rather binary artifacts totally separated from their toolchains.
  - kortex 7y ago
    I find it a huge advantage, in fact the lack of blobs may be my favorite go feature. I'm sure stodgy old companies that want to preserve "IP" through security through obscurity, dislike this model. But as a dev? I can drill down to the core (C-b in Goland, jump to definition) of ANY import. Even the entire go toolchain is in go. ABI/version management of artifacts is a nightmare, every single time.
    - pjmlp 7y ago
      That is what debugging symbols are for. Using binary dependencies doesn't preclude having access to source code if desired.
    - jayd16 7y ago
      Same with Java unless they stripped symbols. Libs wouldn't be stripped though.
  - jwalgenbach 7y ago
    One of the reasons I use go is the production of static, self contained binaries. Wouldn't binary artifacts make that much more difficult?
    - pjmlp 7y ago
      Why should it? Static compiling has been a thing since compilers exist. Dynamic linking only became mainstream in the mid-90s.
    - apta 7y ago
      You can build self-contained Java JAR files for a while now.

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.

pjmlp 7y ago
Actually I find it a disadvantage, I don't want to deal with source code from other teams/companies, rather binary artifacts totally separated from their toolchains.
- kortex 7y ago
  I find it a huge advantage, in fact the lack of blobs may be my favorite go feature. I'm sure stodgy old companies that want to preserve "IP" through security through obscurity, dislike this model. But as a dev? I can drill down to the core (C-b in Goland, jump to definition) of ANY import. Even the entire go toolchain is in go. ABI/version management of artifacts is a nightmare, every single time.
  - pjmlp 7y ago
    That is what debugging symbols are for. Using binary dependencies doesn't preclude having access to source code if desired.
  - jayd16 7y ago
    Same with Java unless they stripped symbols. Libs wouldn't be stripped though.
- jwalgenbach 7y ago
  One of the reasons I use go is the production of static, self contained binaries. Wouldn't binary artifacts make that much more difficult?
  - pjmlp 7y ago
    Why should it? Static compiling has been a thing since compilers exist. Dynamic linking only became mainstream in the mid-90s.
  - apta 7y ago
    You can build self-contained Java JAR files for a while now.