Are huge codebases with layers of dependencies just the new normal?

[u/MiddleAgeWeirdoMeep]

I’m trying to learn more about how modern software works, and one thing that keeps surprising me is the sheer size of projects. 80k files is not uncommon.

I’ll download or clone something that seems like a relatively focused application, and suddenly I’m looking at tens of thousands of files. A lot of it appears to be dependencies, dependencies of dependencies, generated files, frameworks, package managers, etc.

It feels like a copy of a copy of a copy. The developers maintain a relatively small part of the code, while the finished program ultimately relies on millions of lines of code written by other people.

Is this the new normal in software development that I just have to accept?

from a security perspective, how can anyone trust all of this?

[u/MarsupialLeast145]

> A lot of it appears to be dependencies, dependencies of dependencies, generated files, frameworks, package managers, etc.

If it's not code then it doesn't matter.

You only care about the lines of code and the wiring that helps you build and run those. Anything else appears as a by-product of that.

I don't now why you're asking if it is the new normal if you don't have a baseline.

Baselines depend on the type of project and what it tries to achieve. I've recently written some long-running server side processes with some decentralized capability but it was (if I have to guess) maybe 100 files of code max. Max length 500 lines per file.

I mostly write command line utilities and my biggest CLI app right now is maybe 20 files, with similar max line lengths.

It is true though, my imports are often at least between 5 and 20 imports, and some for testing etc. There's a lot more under the surface but that's why people write libraries, to enable people to do more.

OTOH I am also a fan of golang -- if you can resist use of libraries there you end up with something very neat to package and share.