alt Hacker NewsThere 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.
Replies
The goal is not to cover everything, the goal is to cover 90% of the use cases.
For C#, I think they achieved that.
> 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.
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.
Python, .NET, and Java are not examples of batteries included.
Django and Spring
"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.