3 ms·

> Fuzzed, proven correct libraries clearly aren't the problem here. They aren't. I'm steelmanning your position. "What if there exists a set of well audited li

by Ygg2 3y ago

> Fuzzed, proven correct libraries clearly aren't the problem here. They aren't. I'm steelmanning your position. "What if there exists a set of well audited libraries". And "what if we have package managers everyone uses". The logical answer is that everyone reuses them, leading to deeply nested transitive dependencies. Hence a contradiction. Deeply nested libraries aren't a problem. > caused global problems: heartbeat extensions from OpenSSL and LDAP/JDNI from Log4J. Already covered that. How do you disambiguate what is a crucial feature and what is overhead? On surface it seems simple, but constraints, call for features and backwards compatibility guarantees makes that something that only seems obvious in hindsight.

Ygg2 3y ago
Here are my underlying assumptions: - Some set of libraries are fully audited. - Some libraries can't be fully specced and audited because their specs are in flux (e.g. games, GUIs, webapps) - Those libraries/apps will limit their maintenance burden by using audited ones - Package managers are useful. As long as the set of audited libraries is large or tends to grow large, or the audited libraries build upon each other, or the non-audited libraries depend on many other libraries, the "deeply nested" (I don't think it's deeply nested as much as many dependencies) hierarchy will be replicated.
- whstl 3y ago
  Naturally I'm fine with people using even single-function libraries if they're audited, but the problem is that those are the ones who historically are not cared for that much :/ All those assumptions can be all true, but that still doesn't make the overarching assumption right. I would also appreciate if you took a look at my messages with a bit more empathy. I state several times that I'm not advocating for the opposite "NIH syndrome" point of view... this has been implied by you and by the other poster several times, and it's not cool :/
whstl 3y ago
> They aren't. I'm steelmanning your position. Sure, but nevertheless: if this were a reality, sure, it would be perfectly fine! But we don't live in the fantasy world so we have problems. This is why people don't complain about this kind of code being moved to standard libraries: stdlibs they are often heavily audited (with exceptions), So maybe that's a suggestion from me: moving SOME things (NOT ALL) that are traditionally in stdlibs in other languages to the stdlib of your own language. Or another: perhaps force yourself to use primarily audited libraries (parent commenter mentioned NewtonSoft.JSON... this is a good one that is an industry standard). I however still won't bulge that depending on too many mystery libraries is not a good thing :/ > How do you disambiguate what is a crucial feature and what is overhead To keep using the same two examples: if you don't need something for 99% of regular use cases, then it can definitely be optional. But optional doesn't mean the same as "non existent". I'm not advocating removing features or not making it, like another person said. I'm just advocating building software a bit differently. Instead of having 100 features and a lot of dependencies in one root package, have instead 1 base package (with fewer features and fewer dependencies) + N plugin packages (with the remaining features and dependencies). This way you can reduce the blast radius of problematic dependencies without removing features. Naturally you need good DX, the core package must implement something, it can't be just an empty package that doesn't do anything and requires 200 other packages to work. But there are again no silver bullets here.

by Ygg2 3y ago

Ygg2 3y ago

Here are my underlying assumptions: - Some set of libraries are fully audited. - Some libraries can't be fully specced and audited because their specs are in flux (e.g. games, GUIs, webapps) - Those libraries/apps will limit their maintenance burden by using audited ones - Package managers are useful. As long as the set of audited libraries is large or tends to grow large, or the audited libraries build upon each other, or the non-audited libraries depend on many other libraries, the "deeply nested" (I don't think it's deeply nested as much as many dependencies) hierarchy will be replicated.

whstl 3y ago
Naturally I'm fine with people using even single-function libraries if they're audited, but the problem is that those are the ones who historically are not cared for that much :/ All those assumptions can be all true, but that still doesn't make the overarching assumption right. I would also appreciate if you took a look at my messages with a bit more empathy. I state several times that I'm not advocating for the opposite "NIH syndrome" point of view... this has been implied by you and by the other poster several times, and it's not cool :/

whstl 3y ago

> They aren't. I'm steelmanning your position. Sure, but nevertheless: if this were a reality, sure, it would be perfectly fine! But we don't live in the fantasy world so we have problems. This is why people don't complain about this kind of code being moved to standard libraries: stdlibs they are often heavily audited (with exceptions), So maybe that's a suggestion from me: moving SOME things (NOT ALL) that are traditionally in stdlibs in other languages to the stdlib of your own language. Or another: perhaps force yourself to use primarily audited libraries (parent commenter mentioned NewtonSoft.JSON... this is a good one that is an industry standard). I however still won't bulge that depending on too many mystery libraries is not a good thing :/ > How do you disambiguate what is a crucial feature and what is overhead To keep using the same two examples: if you don't need something for 99% of regular use cases, then it can definitely be optional. But optional doesn't mean the same as "non existent". I'm not advocating removing features or not making it, like another person said. I'm just advocating building software a bit differently. Instead of having 100 features and a lot of dependencies in one root package, have instead 1 base package (with fewer features and fewer dependencies) + N plugin packages (with the remaining features and dependencies). This way you can reduce the blast radius of problematic dependencies without removing features. Naturally you need good DX, the core package must implement something, it can't be just an empty package that doesn't do anything and requires 200 other packages to work. But there are again no silver bullets here.