4 ms·

Go’s package and dependency system is actually the only reason I have never started using it more. The lack of true versioning, unspoken assumption of GitHub, p

Go’s package and dependency system is actually the only reason I have never started using it more. The lack of true versioning, unspoken assumption of GitHub, package system, and all of the confusion between god mod, go get, go install, etc. just hurts my brain. I think Rust actually has this perfect. It’s clear. You just specify the name and version and features in the Cargo.toml file and it is pulled from crates.io. No installation-time execution either. As far as binaries, I think Rust beats it out here too. Take path separators for example. It’s completely possible to have a binary in Go that uses the entirely wrong path separators for the OS. Rust forces you to handle this.

amscanne 5y ago
> The lack of true versioning, unspoken assumption of GitHub, package system, These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io? > No installation-time execution either. This is also not true. There is no installation-time execution.
- pjmlp 5y ago
  Nope, there is no relation between a package name and where it is hosted, nor any need to create remappings. As it should be.
  - amscanne 5y ago
    I’m not sure I follow. I assume “as it should be” refers to crates, with no mechanism for name ownership other than first-come, first-served. You name any Go package based on a URL you control (and you can refer to any underlying source control by returning appropriate metadata from that URL). Package names that are URL-based is an arbitrary decision, but it seems like it at least solves that problem. Personally I’m much more a fan of that, since otherwise you need to put far too much faith in a single provider (crates), and enable a whole class of attacks and ownership squabbles. Better to just punt this to the already-solved DNS and web ecosystem. I just can’t agree that a single centralized repository is “as it should be”.
- uncomputation 5y ago
  There is versioning through Git tags, which I don’t consider true versioning because you can always edit those tags to point somewhere else or remove them entirely. This is breaking. I suppose there is not an assumption of GitHub, but rather Git. I probably got that impression from all of the Go documentation using GitHub as an example (perhaps to seem more familiar to readers). No, I _like_ crates.io because Rust is very explicit that that is where the packages come from. We can get into the benefits and risks and whatever about centralized vs decentralized package managers, but that’s not what I’m talking about. I just want to know how Go does what it does so that I can code confidently in it. A lot of Go packages are specified like so: go get -u github.com/username/repo/version But this is not enforced (you don’t have to specify a version) and this is also not a valid Git repo path and where exactly is this dependency stored and I can go on and on. When you import this package it’s usually import “github.com/user/repo/version/module” But then there is not always a <module> directory in the repo and… you get the idea. This sort of stuff hurts my head and I get it that Go is maybe trying to appear simple but this black box handwavey stuff can and will burn you (this very reason is why the Go community is generally against frameworks) so I just want to have a simple, clear answer and it seems no one else in the Go world has any of these questions. This turns me off. I’m confused by your last bit. Neither Rust nor Go have installation time execution and this is good. I was referring to how you can’t just say “Oh Node has it and this is bad but Go doesn’t and this is good” because Rust doesn’t have it either.
  - amscanne 5y ago
    Re: tags, that’s true but builds will detect this and break (since the hash is encoded in the sum file). No one should move tags, ever (for many reasons), and Go is simply requiring this. Re: git, there is no assumption of git. Go also natively supports svn, hg, bzr and fossil. You also have the option to vendor things. It’s fine to favor crates because it’s closer to what you’re used to, but I think you’re just complaining about ergonomics. They both have semver and implement satisfiability in similar ways (AFAIK). It seems like the source control mixin is what’s causing the most frustration, and I get it — that’s where you have ergonomics you’re not used to — however, this is also where Go shines since it essentially gives you supply chain integrity without the need to trust any users uploading code (module owners) or third party vendors (crates). What is the question for which you are looking for a simple, clear answer? Honestly, the documentation is quite excellent [1], but I’m happy to do my best to point to the best place for answers. [1] https://golang.org/ref/mod https://golang.org/ref/mod

amscanne 5y ago

> The lack of true versioning, unspoken assumption of GitHub, package system, These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io? > No installation-time execution either. This is also not true. There is no installation-time execution.

pjmlp 5y ago
Nope, there is no relation between a package name and where it is hosted, nor any need to create remappings. As it should be.
- amscanne 5y ago
  I’m not sure I follow. I assume “as it should be” refers to crates, with no mechanism for name ownership other than first-come, first-served. You name any Go package based on a URL you control (and you can refer to any underlying source control by returning appropriate metadata from that URL). Package names that are URL-based is an arbitrary decision, but it seems like it at least solves that problem. Personally I’m much more a fan of that, since otherwise you need to put far too much faith in a single provider (crates), and enable a whole class of attacks and ownership squabbles. Better to just punt this to the already-solved DNS and web ecosystem. I just can’t agree that a single centralized repository is “as it should be”.
uncomputation 5y ago
There is versioning through Git tags, which I don’t consider true versioning because you can always edit those tags to point somewhere else or remove them entirely. This is breaking. I suppose there is not an assumption of GitHub, but rather Git. I probably got that impression from all of the Go documentation using GitHub as an example (perhaps to seem more familiar to readers). No, I _like_ crates.io because Rust is very explicit that that is where the packages come from. We can get into the benefits and risks and whatever about centralized vs decentralized package managers, but that’s not what I’m talking about. I just want to know how Go does what it does so that I can code confidently in it. A lot of Go packages are specified like so: go get -u github.com/username/repo/version But this is not enforced (you don’t have to specify a version) and this is also not a valid Git repo path and where exactly is this dependency stored and I can go on and on. When you import this package it’s usually import “github.com/user/repo/version/module” But then there is not always a <module> directory in the repo and… you get the idea. This sort of stuff hurts my head and I get it that Go is maybe trying to appear simple but this black box handwavey stuff can and will burn you (this very reason is why the Go community is generally against frameworks) so I just want to have a simple, clear answer and it seems no one else in the Go world has any of these questions. This turns me off. I’m confused by your last bit. Neither Rust nor Go have installation time execution and this is good. I was referring to how you can’t just say “Oh Node has it and this is bad but Go doesn’t and this is good” because Rust doesn’t have it either.
- amscanne 5y ago
  Re: tags, that’s true but builds will detect this and break (since the hash is encoded in the sum file). No one should move tags, ever (for many reasons), and Go is simply requiring this. Re: git, there is no assumption of git. Go also natively supports svn, hg, bzr and fossil. You also have the option to vendor things. It’s fine to favor crates because it’s closer to what you’re used to, but I think you’re just complaining about ergonomics. They both have semver and implement satisfiability in similar ways (AFAIK). It seems like the source control mixin is what’s causing the most frustration, and I get it — that’s where you have ergonomics you’re not used to — however, this is also where Go shines since it essentially gives you supply chain integrity without the need to trust any users uploading code (module owners) or third party vendors (crates). What is the question for which you are looking for a simple, clear answer? Honestly, the documentation is quite excellent [1], but I’m happy to do my best to point to the best place for answers. [1] https://golang.org/ref/mod https://golang.org/ref/mod