i'll never understand dependency count minimization

if my code works, is clean to read, and doesn't take too long to compile, ship it

@er1n dependency count minimization is a bus factor thing as far as I can tell

the bigger your dependency chain is, the higher the chance someone's account gets compromised and suddenly your software is a virus

@ben @er1n yupp, that's definitely a thing: i am responsible for all the dependencies i being in, unless its community can prove otherwise

many dependencies have a community of one maintainer, and not even trivial stuff, i'm talking web frameworks

@er1n imo theres a middle ground. minimizing dependencies shouldnt be the goal, but also every dependency is another way for it to fail on someone elses system due to version mismatch, and another way for things to break in the future when a lib ends up deprecated/unmaintained

@rvc @er1n
Yes, dependency quality should be more important than dependency count. Also depth and the usefulness of your package manager (if any). Some languages have a package manager that'll recurse to arbitrary depth and resolve conflicts. Some languages have luarocks 😂

I'm an old and I like to tell the story about the development community I was in where they were deadlocked over whether to do version 2 in C or rewrite it in something like Ruby. There was this draconian rule about dependencies, too, so I left the original program alone and wrote a wrapper script in the most obscure scripting language that technically satisfied the community requirements

But 20 years later, that program still compiles and runs. So it's not like they were wrong. Just annoying 😎

@er1n love too build a tower out of badly specified parts on a shifting foundation that nobody is responsible for

@scanlime true and valid

i guess i'm looking at the slightly-more-conservative rust style of dependency vendoring more than, for instance, node's. "traditional" dependency management is also kinda bad in a different way (wooooo incompatible shared libraries and reliance on fragmented system package managers or the lack thereof)

@er1n there's gotta be a middle ground between entirely monolithic codebases and npm :)

@er1n I'm kinda torn. On one hand, yes, probably you don't need to depend on `is-odd`. On the other hand, having working code is far better than not, and as long as you're not shipping vulnerabilities and can still maintain your thing, cool.

(That said, I'm currently running into a problem where too many dependencies are slowing down compiles that happen thousands of times a day, so I'm working to cut those down.)

@er1n one version of this i ran into recently is porting to a new platform (arch, os, etc) -- the fewer dependencies, the more likely you can successfully wrangle the whole pile into building for the new target, even if they were not written with it in mind

@cascode i mainly find this to be an issue with like, c and c++ dependency style stuff, not well-done dependency management like rust

@er1n for sure. though i'd be curious as to whether it starts to look similar when you're dealing with vendor-custom compiler triplets (whether rust is vulnerable to e.g. differences in undefined behavior between libc's)... i really don't know! at least a uniform build system probably makes it super easy to attempt the full cross-compilation of all deps, i would hope (which would certainly be a big help)

@cascode @er1n it does -- at work we've managed to put almost everything except the C and C++ standard libraries in packages and it made porting to arm64 astonishingly easy, despite having something like ~25 dependencies in the dep graph

(armhf was harder but mostly because of 32 vs. 64-bit fuckups)

@er1n what about dependencies you refactor out, but forget to remove? does cargo warn about these? do they still get linked into the binary, just to be on the safe side?

@hirojin @er1n dunno about Rust, but in Go, importing a package and not using it is a compile-time error

@ben @er1n (not) importing, yes, but i'm talking about specifying it in Cargo.toml

at the very least it'll be downloaded and compiled

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!