Package managers have their own versions of these problems, and I would suggest that there is a balance here, but it weighs more in favor of standard libraries

Package managers have their own versions of these problems, and I would suggest that there is a balance here, but it weighs more in favor of standard libraries than you think. Here are the package manager problems: 1. Discoverability. Need an unordered map? We've got 20 of them, all made for slightly different use cases. No, their APIs are not cross-compatible. Also, only one of them has documentation and it's only in English/Chinese. 2. Lagging HEAD. Want to develop with the most recent version of the language? Too bad, package Foo was written for Python 2 and is now broken. The maintainer of foo may get around to updating it if you pay him. 3. Compatibility. The standard library runs everywhere. Package Foo only runs on M1 Macs, and has subtle bugs on x86 machines. 4. Supply chain hell. Chances are one of your packages or one of their packages is maintained by one guy. If a core function like left_pad is slow, you're shipping inefficient code. If one of those packages decides that you need to evangelize about how Putin is bad, guess what's showing up in your logs? If one of them gets compromised, you're on the hook for the damage. This practically means a lot of audits or a lot of sleepless nights.