5 ms·

In what world does cost mean file size and not consider financial cost, patching, security auditing, debugging, and the cost of finally ripping it out when ever

In what world does cost mean file size and not consider financial cost, patching, security auditing, debugging, and the cost of finally ripping it out when everyone agrees retrospectively that it was a mistake to include in the first place. Come to think of it, the shortcoming of the description explains a lot of things about the current state of the JavaScript ecosystem.

deleted 2y ago
[deleted]
aragilar 2y ago
I would have thought it would show how big the dependency tree was.
- fmajid 2y ago
  And a count of historical CVEs in its transitive graph.
  - ChrisMarshallNY 2y ago
    CVEs might not be the best metric, alone. Many large, mature, and solid packages could have long histories of resolved CVEs.
    - hsbauauvhabzb 2y ago
      Yes but that would indicate deeply rooted issues in many cases.
      - ChrisMarshallNY 2y ago
        I would say "might," as opposed to "would." Big systems have big surfaces, no matter what quality they are. Dependency chains may be more of an issue. I think several of the last few big exploits have been compromises in fairly small packages, that were incorporated into larger ones. Then, there's the "Bro Coefficient." Who wrote the package should count for a lot. I'd trust a package written by "linus.torvalds," a lot more than one written by "L33tCoder420LOL," even if the Web site is super-sexy, and it has a gazillion GH stars.
    - fmajid 2y ago
      It's still a good measure of how much security risk you are taking from the increased attack surface.
m463 2y ago
> In what world the land of spherical cows... reminds me of https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
bayindirh 2y ago
...explains a lot of things about the current state of the JavaScript, Python, Rust and Go ecosystems. Here, FTFY. IOW, having a package manager in your programming language is a boon and a curse, but more of a latter. People just add a single line to their dependency list, and pull in the literal world. As long as their code runs the way it should, nobody, I mean, nobody cares. This is a huge problem.
- robinsonb5 2y ago
  I find this problem much easier to talk about face-to-face - my catchphrase on th subject involves gestures: "All we've done is trade this kind of complexity <holds hands about two feet apart, vertically> for this kind of complexity <holds hand about four feet apart horizontally>.
- jcelerier 2y ago
  > People just add a single line to their dependency list, and pull in the literal world. So do you prefer the situation in c++ where you just add one dependency, like "boost" or "Qt" and it still pulls in 15M lines of code but now it's just "one" dependency instead of 150?
  - bayindirh 2y ago
    No, I prefer to find and vendor in single libraries which do not come with 15M lines of code. Like Eigen. On the other hand, you can introduce Qt modularly, so you don't have to import all of them. Same for Boost, though I don't use either. I write Go and use Uber's zap for logging. It pulls in uncomfortable amount of code, too. Until I can find something better, I'll continue using it, but I'm not comfortable with it. However, in C++ land, I was able to use standalone libraries like Catch or Eigen which were big, but not unwieldy, and Eigen is also as modular as Boost. So you know what you include and what you do at the end of the day. I'm a big fan of standalone source code repositories which vendor minimum number of libraries (which I strive to develop, too). You need GCC and glibc only. Just make it, use it. "No hidden fees, no games", I may say.
  - ChrisMarshallNY 2y ago
viraptor 2y ago
There's no way to automatically establish those costs, considering that if you want some of that functionality, you take that cost on yourself too.

deleted 2y ago

[deleted]

aragilar 2y ago

I would have thought it would show how big the dependency tree was.

fmajid 2y ago
And a count of historical CVEs in its transitive graph.
- ChrisMarshallNY 2y ago
  CVEs might not be the best metric, alone. Many large, mature, and solid packages could have long histories of resolved CVEs.
  - hsbauauvhabzb 2y ago
    Yes but that would indicate deeply rooted issues in many cases.
    - ChrisMarshallNY 2y ago
      I would say "might," as opposed to "would." Big systems have big surfaces, no matter what quality they are. Dependency chains may be more of an issue. I think several of the last few big exploits have been compromises in fairly small packages, that were incorporated into larger ones. Then, there's the "Bro Coefficient." Who wrote the package should count for a lot. I'd trust a package written by "linus.torvalds," a lot more than one written by "L33tCoder420LOL," even if the Web site is super-sexy, and it has a gazillion GH stars.
  - fmajid 2y ago
    It's still a good measure of how much security risk you are taking from the increased attack surface.

m463 2y ago

> In what world the land of spherical cows... reminds me of https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html

bayindirh 2y ago

...explains a lot of things about the current state of the JavaScript, Python, Rust and Go ecosystems. Here, FTFY. IOW, having a package manager in your programming language is a boon and a curse, but more of a latter. People just add a single line to their dependency list, and pull in the literal world. As long as their code runs the way it should, nobody, I mean, nobody cares. This is a huge problem.

robinsonb5 2y ago
I find this problem much easier to talk about face-to-face - my catchphrase on th subject involves gestures: "All we've done is trade this kind of complexity <holds hands about two feet apart, vertically> for this kind of complexity <holds hand about four feet apart horizontally>.
jcelerier 2y ago
> People just add a single line to their dependency list, and pull in the literal world. So do you prefer the situation in c++ where you just add one dependency, like "boost" or "Qt" and it still pulls in 15M lines of code but now it's just "one" dependency instead of 150?
- bayindirh 2y ago
  No, I prefer to find and vendor in single libraries which do not come with 15M lines of code. Like Eigen. On the other hand, you can introduce Qt modularly, so you don't have to import all of them. Same for Boost, though I don't use either. I write Go and use Uber's zap for logging. It pulls in uncomfortable amount of code, too. Until I can find something better, I'll continue using it, but I'm not comfortable with it. However, in C++ land, I was able to use standalone libraries like Catch or Eigen which were big, but not unwieldy, and Eigen is also as modular as Boost. So you know what you include and what you do at the end of the day. I'm a big fan of standalone source code repositories which vendor minimum number of libraries (which I strive to develop, too). You need GCC and glibc only. Just make it, use it. "No hidden fees, no games", I may say.
- ChrisMarshallNY 2y ago

viraptor 2y ago

There's no way to automatically establish those costs, considering that if you want some of that functionality, you take that cost on yourself too.