4 ms·

There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java): 1. They are not going to include everything. This includes thin

by rhdunn 7mo ago

There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java): 1. They are not going to include everything. This includes things like new file formats. 2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.). 3. Things like data structures, graphics APIs, etc. will have performance characteristics that may be different to your use case. 4. They can't cover all nice use cases such as the different libraries and frameworks for creating games of different genres. For example, Python's XML DOM implementation only implements a subset of XPath and doesn't support parsing HTML. The fact that Python, Java, and .NET have large library ecosystems proves that even if you have a "Batteries Included" approach there will always be other things to add.

CommonGuy 7mo ago
Why would they be out of date? The ecosystems themselves (for example .NET) receives regular updates. Yes, they cannot include everything, but enough that you do not _need_ third party packages.
Groxx 7mo ago
"Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted. Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangerous permission" change approval.
- diablevv 7mo ago
  [dead]
- lokar 7mo ago
  Golang seems to do a good job of keeping the standard library up to date and clean
  - Groxx 7mo ago
    Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's also a v2 of the json package because v1 is similarly full of footguns and lack of reasonable control. The list of quirks to maintain in v2's backport of v1's API in https://github.com/golang/go/issues/71497 https://github.com/golang/go/issues/71497 (or a smaller overview here: https://go.dev/blog/jsonv2-exp https://go.dev/blog/jsonv2-exp) is quite large and generally very surprising to people. The good news here is that it actually is possible to upgrade v1 "in place" and share the code. There's a rather large list of such things. And that's in a language that has been doing a relatively good job. In some languages you end up with Perl/Raku or Python 2/3 "it's nearly a different language and the ecosystem is split for many years" outcomes, but Go is nowhere near that. Because this stuff is in the stdlib, it has taken several years to even discuss a concrete upgrade. For stuff that isn't, ecosystems generally shift rather quickly when a clearly-better library appears, in part because it's a (relatively) level playing field.
    - hu3 7mo ago
      This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and Microsoft to build libraries for me than some random low bus factor person, prone to be hacked at anytime due to bad security practices. Setting up a large JavaScript or Rust project is like giving 300 random people on the internet permission to execute code on my machine. Unless I audit every library update (spoiler: no one does it because it's expensive).
      - Groxx 7mo ago
        Third party libraries have been avoiding those json footguns (and significantly improving performance) for well over a decade before stdlib got it. Same with logging. And it's looking like it will be over two decades for an even slightly reasonable http client. Stuff outside stdlib can, and almost always does, improve at an incomparably faster rate.
- nazcan 7mo ago
  100% to libraries having permissions. If I'm using some code to say compute a hash of a byte array, it should not have access to say the filesystem nor network.
- pjmlp 7mo ago
  > "Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. Except I rather have ossified batteries that solve my problem, even if not as convinient as more modern alternatives, than not having them at all on a given platform.
hvb2 7mo ago
The goal is not to cover everything, the goal is to cover 90% of the use cases. For C#, I think they achieved that.
zymhan 7mo ago
> They are going to be out of date whenever a standard changes (HTML, etc.) You might want to elaborate on the "etc.", since HTML updates are glacial.
- mrits 7mo ago
  glaciers change faster than HTML
  - zymhan 7mo ago
    Oof, I honestly hadn't considered that.
  - Yokohiii 7mo ago
    because there is more human effort
- deleted 7mo ago
  [deleted]
- rhdunn 7mo ago
  The HTML "Living Standard" is constantly updated [1-6]. The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025. The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development. The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions. The schema.org metadata standard [10] is under active development and is currently on version 30. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/selectedcontent https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (New) [2] https://web.dev/baseline/2025 https://web.dev/baseline/2025 -- popover API, plain text content editable, etc. [3] https://web.dev/baseline/2024 https://web.dev/baseline/2024 -- exclusive accordions, declarative shadow root DOM [4] https://web.dev/baseline/2023 https://web.dev/baseline/2023 -- inert attribute, lazy loading iframes [5] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/search https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (Baseline 2023) [6] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (2020) [7] https://en.wikipedia.org/wiki/PNG https://en.wikipedia.org/wiki/PNG [8] https://en.wikipedia.org/wiki/XPath https://en.wikipedia.org/wiki/XPath [9] https://en.wikipedia.org/wiki/Resource_Description_Framework https://en.wikipedia.org/wiki/Resource_Description_Framework [10] https://schema.org/ https://schema.org/
mrits 7mo ago
Python, .NET, and Java are not examples of batteries included. Django and Spring
- spixy 7mo ago
  comparing to Node, .NET is batteries included: built-in Linq vs needing lodash external package, built-in Decimal vs decimal.js package, built-in model validation vs class-validator & class-transformer packages, built-in CSRF/XSRF protection vs csrf-csrf package, I can go on for a while...
- ytpete 7mo ago
  And in fact wasn't a popular Python library just compromised very recently? See https://news.ycombinator.com/item?id=47501426 https://news.ycombinator.com/item?id=47501426. So Python's clearly not "batteries included" enough to avoid this kind of risk.
  - rhdunn 7mo ago
    That's my point. You can have a large standard library like those languages I mentioned, but that isn't going to include everything nor cover every use case, so you'll have external libraries (via PyPi for Python, NuGet for .NET, and Maven for Java/JVM).
- vovavili 7mo ago
  Python's standard library is definitely much more batteries-included than JavaScript's.
  - la_fayette 7mo ago
    depends, JavaScript in the Browser has many useful things available, which I miss with python, e.g., fetch, which in Python you need a separate package like requests to avoid a clunky API. Java had this issue for long time as well, since Java 11 there is the HttpClient with a convenient API.
deleted 7mo ago
[deleted]
deleted 7mo ago
[deleted]

by rhdunn 7mo ago

CommonGuy 7mo ago

Why would they be out of date? The ecosystems themselves (for example .NET) receives regular updates. Yes, they cannot include everything, but enough that you do not _need_ third party packages.

Groxx 7mo ago

"Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted. Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangerous permission" change approval.

diablevv 7mo ago
[dead]
lokar 7mo ago
Golang seems to do a good job of keeping the standard library up to date and clean
- Groxx 7mo ago
  Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's also a v2 of the json package because v1 is similarly full of footguns and lack of reasonable control. The list of quirks to maintain in v2's backport of v1's API in https://github.com/golang/go/issues/71497 https://github.com/golang/go/issues/71497 (or a smaller overview here: https://go.dev/blog/jsonv2-exp https://go.dev/blog/jsonv2-exp) is quite large and generally very surprising to people. The good news here is that it actually is possible to upgrade v1 "in place" and share the code. There's a rather large list of such things. And that's in a language that has been doing a relatively good job. In some languages you end up with Perl/Raku or Python 2/3 "it's nearly a different language and the ecosystem is split for many years" outcomes, but Go is nowhere near that. Because this stuff is in the stdlib, it has taken several years to even discuss a concrete upgrade. For stuff that isn't, ecosystems generally shift rather quickly when a clearly-better library appears, in part because it's a (relatively) level playing field.
  - hu3 7mo ago
    This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and Microsoft to build libraries for me than some random low bus factor person, prone to be hacked at anytime due to bad security practices. Setting up a large JavaScript or Rust project is like giving 300 random people on the internet permission to execute code on my machine. Unless I audit every library update (spoiler: no one does it because it's expensive).
    - Groxx 7mo ago
      Third party libraries have been avoiding those json footguns (and significantly improving performance) for well over a decade before stdlib got it. Same with logging. And it's looking like it will be over two decades for an even slightly reasonable http client. Stuff outside stdlib can, and almost always does, improve at an incomparably faster rate.
nazcan 7mo ago
100% to libraries having permissions. If I'm using some code to say compute a hash of a byte array, it should not have access to say the filesystem nor network.
pjmlp 7mo ago
> "Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. Except I rather have ossified batteries that solve my problem, even if not as convinient as more modern alternatives, than not having them at all on a given platform.

hvb2 7mo ago

The goal is not to cover everything, the goal is to cover 90% of the use cases. For C#, I think they achieved that.

zymhan 7mo ago

> They are going to be out of date whenever a standard changes (HTML, etc.) You might want to elaborate on the "etc.", since HTML updates are glacial.

mrits 7mo ago
glaciers change faster than HTML
- zymhan 7mo ago
  Oof, I honestly hadn't considered that.
- Yokohiii 7mo ago
  because there is more human effort
deleted 7mo ago
[deleted]
rhdunn 7mo ago
The HTML "Living Standard" is constantly updated [1-6]. The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025. The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development. The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions. The schema.org metadata standard [10] is under active development and is currently on version 30. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/selectedcontent https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (New) [2] https://web.dev/baseline/2025 https://web.dev/baseline/2025 -- popover API, plain text content editable, etc. [3] https://web.dev/baseline/2024 https://web.dev/baseline/2024 -- exclusive accordions, declarative shadow root DOM [4] https://web.dev/baseline/2023 https://web.dev/baseline/2023 -- inert attribute, lazy loading iframes [5] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/search https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (Baseline 2023) [6] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (2020) [7] https://en.wikipedia.org/wiki/PNG https://en.wikipedia.org/wiki/PNG [8] https://en.wikipedia.org/wiki/XPath https://en.wikipedia.org/wiki/XPath [9] https://en.wikipedia.org/wiki/Resource_Description_Framework https://en.wikipedia.org/wiki/Resource_Description_Framework [10] https://schema.org/ https://schema.org/

mrits 7mo ago

Python, .NET, and Java are not examples of batteries included. Django and Spring

spixy 7mo ago
comparing to Node, .NET is batteries included: built-in Linq vs needing lodash external package, built-in Decimal vs decimal.js package, built-in model validation vs class-validator & class-transformer packages, built-in CSRF/XSRF protection vs csrf-csrf package, I can go on for a while...
ytpete 7mo ago
And in fact wasn't a popular Python library just compromised very recently? See https://news.ycombinator.com/item?id=47501426 https://news.ycombinator.com/item?id=47501426. So Python's clearly not "batteries included" enough to avoid this kind of risk.
- rhdunn 7mo ago
  That's my point. You can have a large standard library like those languages I mentioned, but that isn't going to include everything nor cover every use case, so you'll have external libraries (via PyPi for Python, NuGet for .NET, and Maven for Java/JVM).
vovavili 7mo ago
Python's standard library is definitely much more batteries-included than JavaScript's.
- la_fayette 7mo ago
  depends, JavaScript in the Browser has many useful things available, which I miss with python, e.g., fetch, which in Python you need a separate package like requests to avoid a clunky API. Java had this issue for long time as well, since Java 11 there is the HttpClient with a convenient API.

deleted 7mo ago

[deleted]

deleted 7mo ago

[deleted]