4 ms·

Helpful? Yes, sort of. Should you have to read that to understand how the module versioning system works? Absolutely not. The Go module system is a debacle. It

Helpful? Yes, sort of. Should you have to read that to understand how the module versioning system works? Absolutely not. The Go module system is a debacle. It's not intuitive and it's badly broken right now.

klodolph 6y ago
The underlying problem is hard. I’m not aware of any packaging system that isn’t a mess. Not making apologetics here, I just don’t know what a good package system looks like.
- Tehnix 6y ago
  Examples of excellent package systems: - Haskell: Stack with stackage (mainly because of stackage) - Rust: Cargo and crates They are both above and beyond the rest of the space.
  - klodolph 6y ago
    Having used both of these... what makes them "excellent"? What makes Cargo and crates different? I'm not convinced that the stackage approach is scalable to larger ecosystems... Haskell has a fraction of Go's popularity.
lacker 6y ago
It does kind of suck. But it’s better than npm... or rubygems... or the python ecosystem... hmm, what language’s package management system doesn’t suck?
- earthboundkid 6y ago
  There’s one I like. It’s in this language from Google.
- bpodgursky 6y ago
  I like Maven. Fight me.
  - gonzo41 6y ago
    #triggered
  - rantwasp 6y ago
    level 35 POM boss. residing in nexus!
  - snuxoll 6y ago
    Won’t fight you - I agree. Every packaging system has stupid faults, but I generally have fewer headaches with Maven than the rest. Say what you want about Maven the build system (I’m not going to die on that hill, even though I also prefer Maven to virtually every other build tool I’ve worked with) - but Maven Central and Maven the Package Manager are solid.
  - meddlepal 6y ago
    Me too.
  - macromagnon 6y ago
    My day job is on a modular monolith that uses mvn. I'm no expert but I've set up some IT's, setup build pipeline from jenkins, configure some plugins on various steps of the lifecycle, etc. and I guess it's ok, xml takes a lot of space though and it gets ridiculous on big code bases. I've been working on an android app and use gradle with the kotlin dsl. I haven't really done any programming with the build steps but this is pretty sexy and doesn't need three open/close tags every plugin. dependencies { implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) implementation("com.google.android.material:material:1.2.0") Gradle used to use groovy dsl, but with kotlin the syntax is more consistent and auto complete is actually useful.
    - meddlepal 6y ago
      I've done a ton of work with both Maven and Gradle and I feel like eventually everyone just ends up back to wanting Maven. The problem with Gradle is that it's flexibility is... dangerous and without some constraint can quickly lead to a lot of pain.
- fiatjaf 6y ago
  This one: https://github.com/tidwall/pkg.sh https://github.com/tidwall/pkg.sh
- jasonjayr 6y ago
  CPAN? JAPH. :)
- rantwasp 6y ago
  yeah no. rubygems/python/npm are stare of the art compared to go. it’s painful to watch people doing mental gymnastics to justify bad/disconnected from reality decisions that were made. it’s pretty sad really if you think about it. that there are legitimate use cases where go is really really well suited for the problem. my vote is on someone coming up with a sane approach at some point and people slowly adopting it.
  - Thaxll 6y ago
    Python package mgmt is aweful between the virtual env you need, pip that install different things on different OS, sometime the exec is no even in your path, I don't recall how many time I had to install awscli because it was broken, on top of that you add all the problem with python 2/3 ( pip3 ect .. ). Pip installing things as root or in your home folder ... From all the mgmt I had to use, Python is by far the worst. Every time I have something in Python to use I pray that pip will install it correctly which is roughly 50% of the cases.
    - skinner927 6y ago
      I take it you’ve never used npm
      - ghthor 6y ago
        I take it you've never used npm for a large project that's spanned multiple years of different developers while supporting multiple versions of your application while also staying up to date with dependencies.
    - rantwasp 6y ago
      this has not been my experience. what you describe usually happens for poorly packed things. also, there is a difference between installing packages and environment management
    - lacker 6y ago
      Yeah, the current state of Python is the worst. Especially in machine learning, it's common that a project only supports one of conda or pip installation, which are often but not always compatible. The idea of storing all dependencies in "requirements.txt" is a good idea but has not standardized across the Python community. IMO all the 2 -> 3 upgrade difficulties have slowed down the development of the Python tooling ecosystem.
srtjstjsj 6y ago
You don't have to read it. It Just Works. If you want bugfixes and enhancements, you upgrade the package. If you want to break your existing code, import a different package. If Haskell followed this principle, cabal hell wouldn't exist. If Windows followed this system, DLL hell wouldn't exist.
- Gibbon1 6y ago
  Far as I've seen Microsoft kinda learned it it's lesson. looks at watch 20 years ago. Makes you wonder about the go team, like where were they exactly between 1985 and 2005?
  - srtjstjsj 6y ago
    They were non-existent and when they did exist they didn't have a billion roads in funding to build everything out before launch.
- tome 6y ago
  Cabal hell hasn't existed for quite a while. See https://cabal.readthedocs.io/en/3.4/nix-local-build-overview.html https://cabal.readthedocs.io/en/3.4/nix-local-build-overview...
  - srtjstjsj 6y ago
    Nix doesn't solve the problem of incompatible versions in one binary. Nix only solves the problem of finding compatible versions if they exist. Cabal hell is more than one problem.
    - shirogane86x 6y ago
      nix-style local builds (although the name is kinda bad) don't really have anything to do with nix, they're only the (admittedly bad) name for the new v2-* style commands (that now, at least as of cabal-3.0.0.0 and higher, are the default)

klodolph 6y ago

The underlying problem is hard. I’m not aware of any packaging system that isn’t a mess. Not making apologetics here, I just don’t know what a good package system looks like.

Tehnix 6y ago
Examples of excellent package systems: - Haskell: Stack with stackage (mainly because of stackage) - Rust: Cargo and crates They are both above and beyond the rest of the space.
- klodolph 6y ago
  Having used both of these... what makes them "excellent"? What makes Cargo and crates different? I'm not convinced that the stackage approach is scalable to larger ecosystems... Haskell has a fraction of Go's popularity.

lacker 6y ago

It does kind of suck. But it’s better than npm... or rubygems... or the python ecosystem... hmm, what language’s package management system doesn’t suck?

earthboundkid 6y ago
There’s one I like. It’s in this language from Google.
bpodgursky 6y ago
I like Maven. Fight me.
- gonzo41 6y ago
  #triggered
- rantwasp 6y ago
  level 35 POM boss. residing in nexus!
- snuxoll 6y ago
  Won’t fight you - I agree. Every packaging system has stupid faults, but I generally have fewer headaches with Maven than the rest. Say what you want about Maven the build system (I’m not going to die on that hill, even though I also prefer Maven to virtually every other build tool I’ve worked with) - but Maven Central and Maven the Package Manager are solid.
- meddlepal 6y ago
  Me too.
- macromagnon 6y ago
  My day job is on a modular monolith that uses mvn. I'm no expert but I've set up some IT's, setup build pipeline from jenkins, configure some plugins on various steps of the lifecycle, etc. and I guess it's ok, xml takes a lot of space though and it gets ridiculous on big code bases. I've been working on an android app and use gradle with the kotlin dsl. I haven't really done any programming with the build steps but this is pretty sexy and doesn't need three open/close tags every plugin. dependencies { implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) implementation("com.google.android.material:material:1.2.0") Gradle used to use groovy dsl, but with kotlin the syntax is more consistent and auto complete is actually useful.
  - meddlepal 6y ago
    I've done a ton of work with both Maven and Gradle and I feel like eventually everyone just ends up back to wanting Maven. The problem with Gradle is that it's flexibility is... dangerous and without some constraint can quickly lead to a lot of pain.
fiatjaf 6y ago
This one: https://github.com/tidwall/pkg.sh https://github.com/tidwall/pkg.sh
jasonjayr 6y ago
CPAN? JAPH. :)
rantwasp 6y ago
yeah no. rubygems/python/npm are stare of the art compared to go. it’s painful to watch people doing mental gymnastics to justify bad/disconnected from reality decisions that were made. it’s pretty sad really if you think about it. that there are legitimate use cases where go is really really well suited for the problem. my vote is on someone coming up with a sane approach at some point and people slowly adopting it.
- Thaxll 6y ago
  Python package mgmt is aweful between the virtual env you need, pip that install different things on different OS, sometime the exec is no even in your path, I don't recall how many time I had to install awscli because it was broken, on top of that you add all the problem with python 2/3 ( pip3 ect .. ). Pip installing things as root or in your home folder ... From all the mgmt I had to use, Python is by far the worst. Every time I have something in Python to use I pray that pip will install it correctly which is roughly 50% of the cases.
  - skinner927 6y ago
    I take it you’ve never used npm
    - ghthor 6y ago
      I take it you've never used npm for a large project that's spanned multiple years of different developers while supporting multiple versions of your application while also staying up to date with dependencies.
  - rantwasp 6y ago
    this has not been my experience. what you describe usually happens for poorly packed things. also, there is a difference between installing packages and environment management
  - lacker 6y ago
    Yeah, the current state of Python is the worst. Especially in machine learning, it's common that a project only supports one of conda or pip installation, which are often but not always compatible. The idea of storing all dependencies in "requirements.txt" is a good idea but has not standardized across the Python community. IMO all the 2 -> 3 upgrade difficulties have slowed down the development of the Python tooling ecosystem.

srtjstjsj 6y ago

You don't have to read it. It Just Works. If you want bugfixes and enhancements, you upgrade the package. If you want to break your existing code, import a different package. If Haskell followed this principle, cabal hell wouldn't exist. If Windows followed this system, DLL hell wouldn't exist.

Gibbon1 6y ago
Far as I've seen Microsoft kinda learned it it's lesson. looks at watch 20 years ago. Makes you wonder about the go team, like where were they exactly between 1985 and 2005?
- srtjstjsj 6y ago
  They were non-existent and when they did exist they didn't have a billion roads in funding to build everything out before launch.
tome 6y ago
Cabal hell hasn't existed for quite a while. See https://cabal.readthedocs.io/en/3.4/nix-local-build-overview.html https://cabal.readthedocs.io/en/3.4/nix-local-build-overview...
- srtjstjsj 6y ago
  Nix doesn't solve the problem of incompatible versions in one binary. Nix only solves the problem of finding compatible versions if they exist. Cabal hell is more than one problem.
  - shirogane86x 6y ago
    nix-style local builds (although the name is kinda bad) don't really have anything to do with nix, they're only the (admittedly bad) name for the new v2-* style commands (that now, at least as of cabal-3.0.0.0 and higher, are the default)