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.
The Go module system is a debacle. It's not intuitive and it's badly broken right now.
Not making apologetics here, I just don’t know what a good package system looks like.
- Haskell: Stack with stackage (mainly because of stackage)
- Rust: Cargo and crates
They are both above and beyond the rest of the space.
I'm not convinced that the stackage approach is scalable to larger ecosystems... Haskell has a fraction of Go's popularity.
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.
looks at watch
20 years ago.
Makes you wonder about the go team, like where were they exactly between 1985 and 2005?
Of course, if this increased the number of forks, it would increase the times we need to convert between types provided by "different" libraries - which may or may not be a problem, but isn't "a Cabal problem".
How it would actually work out in practice would depend a lot on how it shaped behavior; it sounds like srtjstjsj believes it went well for go, and I don't know enough to weigh in there in either direction.
I just wanted to point out that the big problems with dependencies in the Haskell ecosystem, sometimes called "cabal hell", have not existed for at least the last few years (since the introduction of v2-style builds).
Exactly!
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.
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")
The problem with Gradle is that it's flexibility is... dangerous and without some constraint can quickly lead to a lot of pain.
JAPH. :)
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.
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.
also, there is a difference between installing packages and environment management