4 ms·

I really like a lot of the distribution- and safety-related decisions Go modules made. Domain names and the proxy+sumdb are wonderfully clear, flexible, and sca

by Groxx 4y ago

I really like a lot of the distribution- and safety-related decisions Go modules made. Domain names and the proxy+sumdb are wonderfully clear, flexible, and scalable, and I think we'll see copies of it in many future languages. The rest of the stuff around modules, like crippled constraints, zero control over contents (which they have changed!), and completely non-existent "x is available, upgrade" or release tooling: constant, unnecessary pain, and it'll be inflicting serious damage on the ecosystem for many years to come.

verdverm 4y ago
> crippled constraints Do you mean ranges on dep versions? The way it is currently, the version you set is the minimum, and the algo finds the highest minimum set across all deps and uses that. If ranges were introduced, you'd end up with an NP hard problem and need a SAT solver for your deps again > Release tooling What are you looking for here? Libraries only need to push a git tag, binaries do require a bit of work, but Goreleaser fills that pretty nicely. It would seem hard to standard where binaries would be pushed > completely non-existent "x is available, upgrade" https://go.dev/doc/modules/managing-dependencies#discovering_updates https://go.dev/doc/modules/managing-dependencies#discovering... "go list -m -u all"
- Groxx 4y ago
  I'm continually confused why SAT solving is seen as a bad thing. It automatically solves common real-world problems in less than a second even in absurdly extreme cases, and a couple milliseconds normally - why would you avoid it?
  - verdverm 4y ago
    Did I say SAT was bad? Go's algorithm is much simpler and does not need a lockfile while still giving deterministic results. Ranged deps without a lockfile cannot. There is benefit to two people running the same command and getting the same dependency versions. Most projects do not start with a lockfile, so it is quite easy to have different versions when running getting started commands. Another example, if I install two ranged dependencies in both orders, will I get the same final deps@version list? Why choose SAT over simpler deterministic algos?

by Groxx 4y ago

verdverm 4y ago

> crippled constraints Do you mean ranges on dep versions? The way it is currently, the version you set is the minimum, and the algo finds the highest minimum set across all deps and uses that. If ranges were introduced, you'd end up with an NP hard problem and need a SAT solver for your deps again > Release tooling What are you looking for here? Libraries only need to push a git tag, binaries do require a bit of work, but Goreleaser fills that pretty nicely. It would seem hard to standard where binaries would be pushed > completely non-existent "x is available, upgrade" https://go.dev/doc/modules/managing-dependencies#discovering_updates https://go.dev/doc/modules/managing-dependencies#discovering... "go list -m -u all"

Groxx 4y ago
I'm continually confused why SAT solving is seen as a bad thing. It automatically solves common real-world problems in less than a second even in absurdly extreme cases, and a couple milliseconds normally - why would you avoid it?
- verdverm 4y ago
  Did I say SAT was bad? Go's algorithm is much simpler and does not need a lockfile while still giving deterministic results. Ranged deps without a lockfile cannot. There is benefit to two people running the same command and getting the same dependency versions. Most projects do not start with a lockfile, so it is quite easy to have different versions when running getting started commands. Another example, if I install two ranged dependencies in both orders, will I get the same final deps@version list? Why choose SAT over simpler deterministic algos?