3 ms·

I think the desire for batteries to be included is a holdover from the time of really really bad (or no) package managers. With a good package manager it doesn'

I think the desire for batteries to be included is a holdover from the time of really really bad (or no) package managers. With a good package manager it doesn't matter if your batteries come included or not. It also provides a way for packages to battle it out external to the language -- compare Python’s `urllib` and `requests`.

galangalalgol 4y ago
The curation of the batteries is the value add. Which grpc package do I want? Which json? Which random number generator? Finding which rust crate is the norm for any given thing, is a task in itself. Then there is the security aspect. Pulling in hundreds of repos with many authors each, is a security risk.
- tialaramex 4y ago
  The curation you're relying on is probably not delivering what you hope. If you picked a Rust crate by looking at a SO answer from say 2020, you're probably getting a similar quality of "curation" in Python's standard libraries. Not because the Python maintainers are intentionally doing a bad job, it's just that their mission isn't to substitute for your research. To them, "Does last year's Python script still work?" is always higher priority than "What's the best way to do it today?". And what Python's security team decide constitutes a reasonable security fix may conflict pretty badly with what you need.
  - ShredKazoo 4y ago
    SO would disable a question of this type for being opinion-based. I would assume the Python devs review the code for a package before including it in the standard lib, right? That seems like a pretty big deal, well beyond someone just telling you that they tried a package and it worked for them.
  - adrianN 4y ago
    "Does last year's code still work" is very important to almost all programmers. I wouldn't want to accidentally use a library that gets abandoned or deprecated a few months after I made it an integral part of my software. Being able to mostly stick to the standard lib makes this a lot easier.
    - tialaramex 4y ago
      That works for Rust's standard library, which won't abandon anything stable (stuff gets deprecated, but that just results in a build warning). It doesn't make as much sense for Python's standard library where you'd need to be paying attention to goings-on in the community to know if one of the batteries that are included has been judged expired and will be removed.
dchftcs 4y ago
This argument is also a holdover from a time where supply chain attacks weren't considered a serious threat.
- porcoda 4y ago
  Exactly. The single biggest hurdle for me using some open source tools written with newer languages is the ridiculous dependency surface due to a preference for package repositories over curated “batteries included” bundled libraries. I work in an environment that is hyper sensitive to supply chain integrity, which means a lot of languages that have a culture of “use all the third party packages” are out for us. Give me a batteries included standard library please - much easier to audit and track.
  - bitwize 4y ago
    Nearly every place I've worked, the supply chain attack problem has been solved or at least mitigated by using an Artifactory instance with a curated list of packages.

galangalalgol 4y ago

The curation of the batteries is the value add. Which grpc package do I want? Which json? Which random number generator? Finding which rust crate is the norm for any given thing, is a task in itself. Then there is the security aspect. Pulling in hundreds of repos with many authors each, is a security risk.

tialaramex 4y ago
The curation you're relying on is probably not delivering what you hope. If you picked a Rust crate by looking at a SO answer from say 2020, you're probably getting a similar quality of "curation" in Python's standard libraries. Not because the Python maintainers are intentionally doing a bad job, it's just that their mission isn't to substitute for your research. To them, "Does last year's Python script still work?" is always higher priority than "What's the best way to do it today?". And what Python's security team decide constitutes a reasonable security fix may conflict pretty badly with what you need.
- ShredKazoo 4y ago
  SO would disable a question of this type for being opinion-based. I would assume the Python devs review the code for a package before including it in the standard lib, right? That seems like a pretty big deal, well beyond someone just telling you that they tried a package and it worked for them.
- adrianN 4y ago
  "Does last year's code still work" is very important to almost all programmers. I wouldn't want to accidentally use a library that gets abandoned or deprecated a few months after I made it an integral part of my software. Being able to mostly stick to the standard lib makes this a lot easier.
  - tialaramex 4y ago
    That works for Rust's standard library, which won't abandon anything stable (stuff gets deprecated, but that just results in a build warning). It doesn't make as much sense for Python's standard library where you'd need to be paying attention to goings-on in the community to know if one of the batteries that are included has been judged expired and will be removed.

dchftcs 4y ago

This argument is also a holdover from a time where supply chain attacks weren't considered a serious threat.

porcoda 4y ago
Exactly. The single biggest hurdle for me using some open source tools written with newer languages is the ridiculous dependency surface due to a preference for package repositories over curated “batteries included” bundled libraries. I work in an environment that is hyper sensitive to supply chain integrity, which means a lot of languages that have a culture of “use all the third party packages” are out for us. Give me a batteries included standard library please - much easier to audit and track.
- bitwize 4y ago
  Nearly every place I've worked, the supply chain attack problem has been solved or at least mitigated by using an Artifactory instance with a curated list of packages.