3 ms·

Idk about Go, but Rust’s cargo seems nice, clean yet powerful. That was my impression some time ago. But last week I attempted to compile a couple of (not ver

Idk about Go, but Rust’s cargo seems nice, clean yet powerful. That was my impression some time ago. But last week I attempted to compile a couple of (not very big) tools from cargo. And it ended up downloading hundreds of dependencies and gigabytes of packages. Looks like node_modules.jpg all over again :(

verdverm 4y ago
> Idk about Go I wrote a post highlighting Go's mod system: https://verdverm.com/go-mods/ https://verdverm.com/go-mods/ imo, it is the best designed dependency system I know of. One of the nice things is that Go uses a shared module cache so there is only one copy on your computer when multiple projects use the same dependency@version
- omgtehlion 4y ago
  I think, this is not a problem with package manager per se. But with extremities of coding culture. On one side of the spectrum is “NIH” and reinvent everything yourself. On the other side is: let’s pull left-pad from package, because packages are good, we need MORE PACKAGES. The best solution always lies somewhere in the middle. But finding this “middle” (and adhering to this approach) is the hard part.
  - marcus_holmes 4y ago
    I think I'm on the NIH side of things. Not because I like inventing things (well, partially), but because of the security problem [0]. I don't see it being talked about here, either. Our current system of pulling in packages made by random people on the internet is going to burn us. We assume that everyone who creates a package is an honest, reliable, developer who will not inject malicious code into their package. This assumption is similar to the assumptions we made around SMTP, HTTP, DNS, and every other internet protocol. Turns out we were wrong and surprise! you can't trust people on the internet. I'm not sure if we can solve this with package managers. But package managers are part of the culture that has created this problem, and are probably a reasonable starting point to try and address it. [0]:https://david-gilbertson.medium.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://david-gilbertson.medium.com/im-harvesting-credit-car...
- 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?
junon 4y ago
As someone who contributed somewhat extensively to the node_modules problem early on, Cargo is definitely better than the JS ecosystem in this regard. Further, another major difference is that you don't need those dependencies after you've built. You can blow them away. Doing that with node is not as straightforward, and in many cases, not possible.

verdverm 4y ago

> Idk about Go I wrote a post highlighting Go's mod system: https://verdverm.com/go-mods/ https://verdverm.com/go-mods/ imo, it is the best designed dependency system I know of. One of the nice things is that Go uses a shared module cache so there is only one copy on your computer when multiple projects use the same dependency@version

omgtehlion 4y ago
I think, this is not a problem with package manager per se. But with extremities of coding culture. On one side of the spectrum is “NIH” and reinvent everything yourself. On the other side is: let’s pull left-pad from package, because packages are good, we need MORE PACKAGES. The best solution always lies somewhere in the middle. But finding this “middle” (and adhering to this approach) is the hard part.
- marcus_holmes 4y ago
  I think I'm on the NIH side of things. Not because I like inventing things (well, partially), but because of the security problem [0]. I don't see it being talked about here, either. Our current system of pulling in packages made by random people on the internet is going to burn us. We assume that everyone who creates a package is an honest, reliable, developer who will not inject malicious code into their package. This assumption is similar to the assumptions we made around SMTP, HTTP, DNS, and every other internet protocol. Turns out we were wrong and surprise! you can't trust people on the internet. I'm not sure if we can solve this with package managers. But package managers are part of the culture that has created this problem, and are probably a reasonable starting point to try and address it. [0]:https://david-gilbertson.medium.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://david-gilbertson.medium.com/im-harvesting-credit-car...
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?

junon 4y ago

As someone who contributed somewhat extensively to the node_modules problem early on, Cargo is definitely better than the JS ecosystem in this regard. Further, another major difference is that you don't need those dependencies after you've built. You can blow them away. Doing that with node is not as straightforward, and in many cases, not possible.