Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Large standard libraries are a major pain for evolving the language and the libraries in question. (E.g. Python's standard library is notorious as "where modules go to die"). Putting each piece into its own library is great as long as your tooling can manage them effectively.

What could be useful is some concept of a "metalibrary" or "platform", a la the "rust platform" and "haskell platform" efforts - a sensible aggregate of libraries with compatible versions that work together and cover most of the common things you need - not as an inflexible monolith that you have to do big-bang upgrades of, but as a starting point that you can then customize as needed. Almost like a Linux distribution. But keeping the ability to upgrade one small piece without touching the others is really important.



Things like string manipulation, array manipulation or similar are pretty well understood and could be put into a comprehensive library. On the few more projects I have seen there were some trivial packages like “isodd” or something like this which then recursively pulled in dozens of other trivial stuff. This just doesn’t seem to be a problem in other languages.


Major upgrade problems because of supposedly simple, well-understood library matters like string manipulation or array manipulations are definitely a problem that other languages have - just look at the whole Python 3 saga.


.NET doesn’t have that problem or C


C doesn't have even basic string operations in its standard library. It could do with a lot more libraries but is hampered by not having any kind of dependency management tooling. Where there are monolithic libraries, upgrading is absolutely a problem, but a lot of functionality in C is just not there, which ends up with a lot of duplicated code, snippets copied and pasted or simply reimplemented in every project, and all the associated maintainability and security problems.

.net I'm less familiar with, but I've certainly heard of projects being stuck on older versions of it, and again for a lot of tasks it tends to be a case of there just not being a library available at all.


.NET suffered from the fact that you couldn't move easily between versions. This changed with .NET Core, where you can target (and install multiple versions of) different instances of the runtime/SDK.

That, combined with the ability to target .netstandard and a much more clear line of sight for what is compatiable with those standards, have made this, to me, a non issue.

It was historically though, very hard to deal with for large apps.


Again I'm not really part of that ecosystem, but it sounded to me like .net core/standard involved doing exactly what Ididntdothis was arguing against - moving functionality out of the language standard library and into separate libraries with their own independent versioning.


before I say more, I just want to clarify I meant no ill direction or intent your way. I genuinely think there is a fine balance to be struck between a good stdlib & just moving things into the broader module ecosystem for any language. Some get it more right than others (Go Lang, for instance, I think is cool, in that it has the stdlib, but if I understand it correctly the stdlib is maintained as separate installable libs)

Microsoft hasn't move much out of the core C#/.NET libaries, rather they made it easier to interop the SDKs/runtimes. The actual libaries themselves haven't changed much in respect to this issue.


The reason I don't believe it's a balance is simply that I haven't seen a downside. The world has drifted towards microlibraries largely because of real advantages, brought on by automated package management making them practical. People here seem to be grasping at straws to find a justification for disliking that change.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: