4 ms·
Not defending the import versioning strategy, but I found it helpful to read Russ Cox’s writeup on the topic: https://research.swtch.com/vgo-import https://rese
by maxmcd 6y ago
Not defending the import versioning strategy, but I found it helpful to read Russ Cox’s writeup on the topic: https://research.swtch.com/vgo-import https://research.swtch.com/vgo-import
- meddlepal 6y agoHelpful? 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 agoThe 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 agoExamples 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 agoHaving 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 agoIt 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 agoThere’s one I like. It’s in this language from Google.
- bpodgursky 6y agoI like Maven. Fight me.
- gonzo41 6y ago#triggered
- rantwasp 6y agolevel 35 POM boss. residing in nexus!
- snuxoll 6y agoWon’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 agoMe too.
- macromagnon 6y agoMy 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.
- srtjstjsj 6y agoYou 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 agoFar 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 agoThey 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 agoCabal 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 agoNix 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 agonix-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)