| ▲ | Yoric 3 days ago | |
The thing is, having access to such dependencies is also a huge productivity boost. It's not by accident that every single language whose name isn't C or C++ has pretty much moved to this model (or had it way before npm, in the case of Perl or Haskell). The alternative is C++, where every project essentially starts by reinventing the wheel, which comes with its own set of vulnerabilities. I'm saying this without a clear idea of how to fix this very real problem. | ||
| ▲ | fdsfdsfdsaasd 3 days ago | parent | next [-] | |
It's more like capex vs opex. Some languages and frameworks - you have to maintain the same level of effort, just to keep your apps working. | ||
| ▲ | fooker 3 days ago | parent | prev [-] | |
> The alternative is C++, where every project essentially starts by reinventing the wheel Sure, in 1995. Most C++ projects nowadays belong to some fairly well understood domain and for every broad domain there is usually one or two large 'ecosystem' libraries that come batteries included. Huge monolithic dependency with well stablished governance instead of 1000 small ones. Examples of such ecosystems are Qt, LLVM, ROOT, tensorflow, etc. For smaller projects that want something slightly more than a standard library but not belonging to a clear ecosystem like the above you have boost, folly, abseil, etc. Most of these started by someone deciding to reinvent the wheel decades ago, but there's no real reason to do that in 2025. | ||