Ask HN: What should be included in a standard library? | Hacker News Reader

Ask HN: What should be included in a standard library?

5 pointsvodou6 comments

I know, I know... There are countless "it depends" baked into this question. But let’s try anyway.

After reading HN for years, I have encountered so many opinions regarding standard libraries in various programming languages, e.g., how they should be designed, what they should (and should not) include, etc.

The C standard library is very minimal, focusing mostly on low-level facilities. Everyone is expected to implement their own dynamic arrays or choose one implementation from a zillion available libraries. And, apparently, null-terminated strings are the work of the devil. C++ has a much more extensive standard library, built around generic programming techniques using containers, iterators, and algorithms applied in a composable way. It is rather elegant and powerful, but not very intuitive for beginners. It also has some notable omissions compared to more modern languages. Python comes with "batteries included" in the form of a very rich standard library. However, the PSF tends to "break user space" from time to time by deprecating older modules, such as “boring” technologies like CGI or modules with known security problems. (I am not comfortable enough to say anything about JS, Go, Rust, etc.)

So, what would a great standard library look like? What would make you happy? What have we learned about this after 50+ years of computing? Do you want everything from linked lists to red-black trees (and beyond)? Graphics and sound? (Even if no single API can please everyone.) XML? YAML? SIMD abstractions? Where do you even stop without causing anger? Where do you begin?

(No, I am not creating a new programming language. Enough is enough.)

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.

The C standard library is hamstrung by undefined behaviour versus implementation defined behaviour. This kills all attempts at offering reliable overflow-checks.

The biggest fulcrum is: Can developers also build a complete copy of the standard library or must you be a language implementor? This is what killed Elm. And both Java and Clojure survived. Even a tool like a debugger can be added to the hotspot VM by developers as opposed to just language implementors. Yes, there are many details, but it isn’t precluded on principle.

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.

Reply on news.ycombinator.com