At this point I wouldn't be upset if chrono, serde, and serde_json were folded into the stdlib, but their interfaces are so much better for having been allowed to evolve outside of the strict forever-compatibility requirements of the stdlib.
But http, networking, and database drivers really do not belong in the stdlib. These libraries are so complex and not at all one-size-fits-all. Just take a look at hyper vs. reqwest. They are both http client libs with over 600 million downloads, but they satisfy totally different use cases (lower-level systems and servers vs. batteries-included application code, respectively). How do you reconcile this in the stdlib?
This is not an either or. Sockets are shipped in almost all languages by now. Other than that, I'm thinking of Python's urllib (abstracted upon in requests) or sqlite library, Java's upcoming simple JSON parser, JDBC, or http client and the kotlinx/ktor libraries (serialization, datetime, coroutines, IO, http client, etc).
Existing libraries can be built on top of libraries shipped in core and you can still ship specific libraries for more specific use cases. It just prevents you from reaching for a library if you need to make 1-3 http requests in your application.
PS: I'd argue that almost all issues are caused by outsourcing async to libraries like Tokio, forcing a split of the ecosystem.
5
u/piesou 11d ago edited 11d ago
Pretty sure we can all agree on DateTime, JSON, HTTP client, Serialization/Deserialization, UUID, crypto, networking, and common database drivers.