For a large enough project, the dependency conflicts can get extremely frustrating, especially when it's time to update them. You may need to upgrade a dependency for security reasons cough cough requests cough cough, but some other dependency that calls it has pinned another version (range).
Dependency conflicts become an issue for large projects in any language. It's less of a problem when the language's runtime is feature-rich since libraries will be less likely to use a third-party HTTP client. You can choose libraries with fewer dependencies, but that only gets you so far. At some point, you can put the libraries in you monorepo, but upgrades come with a large cost.
Yeah that is a nightmare. But isn’t that a problem on all package systems except more dynamic runtimes like NPM which can load many copies of the same library?
It's a problem all languages have, but some are better at sorting it out. The way NPM does it solves one issue, but causes others.
The big issue, IMHO, is that when you're dealing with interpreted languages it's very hard to lock down issues before runtime. With compiled or statically typed languages you tend to know a lot sooner where issues lie.
I've had to update requests to deal with certificate issues (to support more modern ciphers/hashes etc) but I won't know until runtime if it even works.
