If all libraries are tiny then a set of “the best” libraries can evolve over time through the preferences of individual people.
Obviously this doesn’t work so well for finding libraries or having them work great together.
If all libraries are tiny then a set of “the best” libraries can evolve over time through the preferences of individual people.
Obviously this doesn’t work so well for finding libraries or having them work great together.
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.
.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.
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.
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.