• So, to expound on this a little…

    There’s a password manager I use, but the CLI tooling sucks. Thankfully, there’s a third party CLI tool in a language I know fairly well, and because I’m a little paranoid, I reviewed the code. Then I reviewed the code of the libraries it imported. And then the code of the libraries of the libraries it imported. Thankfully, that was as far as it went, and I was mainly looking for any code that made network calls… it was manageable, just barely.

    And I made some improvements and submitted PRs, only some of which were accepted, but I used them so I maintained a fork. Which was lucky, because a few months later upstream changed their parseargs library to a framework, and the dependencies exploded. 6 layers deep, and dozens of new dependencies - utterly unauditable without massive effort. I caught it only because of the rebase from upstream. I abandoned the rebase and now maintain a hard fork, of which I’m the only user AFAIK.

    The moral of the story is that introducing dependencies under the guise of “reuse” is a poisoned fruit, a Trojan Horse. It sounds good, but isn’t worth it in the long run. The Go team got it right with their proverb: a little copying is better than a little dependancy.

    • platypus_plumba@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      9 months ago

      Honestly, I don’t like the Go way. If they are going to have that philosophy, at least they should have provided a strong core with high level functions and generics. From the start. Not 5 years later.