The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd

The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd have to write a lot of glue-code to let these libraries talk to eachother. This is a real problem, certainly. In very bad cases (anyone remember programming COM from C++?) the burden of making a simple function call from one part of your code to another can be soul-destroying. This is why I think the modern kitchen-sink standard libraries might be missing a trick. Instead of trying to provide everything out of the box, often to an acceptable but not best-in-class standard, what if our programming languages concentrated on just establishing conventions and providing universal tools with relatively small standard libraries, and then emphasized tools to connect different libraries from other sources together? That is, could they make it easier not just to import modules from different libraries but also to convert data types and match calling conventions and initialize/close down run-time systems? Plenty of ideas have already started down this path, from implicit type conversions or coercion to full-blown lens libraries, simple calling convention annotations to full-blown FFIs and wrappers, and so on. However, to my knowledge, no mainstream language today has an explicit design goal to make integration of multiple modules that have related functionality but different conventions as easy as possible. I wonder how far we could run with that strategy.