I like to think of this as a analogy to biology. Consider this question in the context of say DNA. What DNA strands should be present in the "standard library".
In practice there's no right answer to this - I mean sad library for plants? Animals? Fungi? The question quickly becomes meaningless because without a lot more context there's no right answer.
In the scope of language - is this for embedded programs? Desktops? Phones? Is it for system components? Is it going to talk to hardware? Or networks? Is it headless or heavy UI? What OS is it running on? Is it for writing CRUD apps? Or games? Will it be used in space?
Every context brings different trade offs. Different boundaries, different resources, different everything.
Thus every answer to your question is both true for some places, and false in others.
Thus variety in context is what leads us to the current situation- lots of options.
Like Wikipedia tries to catalogue all useful knowledge in the world, a standard library should catalogue all useful modules in the world. The problem is that tools and community structures we have are not advanced enough to support that workflow yet. E.g., it's difficult to see how you could put PyTorch into Python's standard library and have all developers happy with that. But it would make a lot of "meta" issues easier, such as release management, consistent documentation, community relations, etc.
If you can possibly include the "magic" strings that Free Pascal has, you'll be light years ahead of just plain C strings. They're counted, reference counted, and copy on modify. You don't have to allocate/free them, and they can contain gigabytes of ASCII, Unicode, or Binary data.
HTTP server and related parsers (just a basic one), URL parsing and escaping, JSON, Socket handling, timers, interactive debugger, basic templating library, WebSocket client, SQLite.
I think Ruby got it right in this regard and Bun comes close as a second place.
I like to think of this as a analogy to biology. Consider this question in the context of say DNA. What DNA strands should be present in the "standard library".
In practice there's no right answer to this - I mean sad library for plants? Animals? Fungi? The question quickly becomes meaningless because without a lot more context there's no right answer.
In the scope of language - is this for embedded programs? Desktops? Phones? Is it for system components? Is it going to talk to hardware? Or networks? Is it headless or heavy UI? What OS is it running on? Is it for writing CRUD apps? Or games? Will it be used in space?
Every context brings different trade offs. Different boundaries, different resources, different everything.
Thus every answer to your question is both true for some places, and false in others.
Thus variety in context is what leads us to the current situation- lots of options.
Like Wikipedia tries to catalogue all useful knowledge in the world, a standard library should catalogue all useful modules in the world. The problem is that tools and community structures we have are not advanced enough to support that workflow yet. E.g., it's difficult to see how you could put PyTorch into Python's standard library and have all developers happy with that. But it would make a lot of "meta" issues easier, such as release management, consistent documentation, community relations, etc.
If you can possibly include the "magic" strings that Free Pascal has, you'll be light years ahead of just plain C strings. They're counted, reference counted, and copy on modify. You don't have to allocate/free them, and they can contain gigabytes of ASCII, Unicode, or Binary data.
I love this question.
HTTP server and related parsers (just a basic one), URL parsing and escaping, JSON, Socket handling, timers, interactive debugger, basic templating library, WebSocket client, SQLite.
I think Ruby got it right in this regard and Bun comes close as a second place.
Go has a nice std, and interfaces that make it easy to add on top instead of reinventing the wheel.
I think as long as a language offers the basics (like streams, etc) it’s not that bad to build on top of it.