> ... language because the ease of adding external libraries has an enormous impact on the design choices...

even if you could incorporate external libraries with zero impedance mismatch, you still have to _use_ the said libraries.

while there might be _marginal_ element of truth to that statement, however ease of stitching external libraries into your application has no bearing on either the programming language or the act of programming the application itself.

I don't understand what you're trying to say. Of course the effort to include the library in the project and keep it up to date has an impact on the decision whether I use it or whether I just roll my own. There is a reason that my Rust projects have dozens of dependencies whereas in C++ I basically restrict myself to boost or other header-only libraries.

> I don't understand what you're trying to say.

simple, ease of integrating external libraries into a project has _nothing_ to do with the programming language.

they are at best two orthogonal topics.

50% of the popularity of modern languages like golang and rust comes from the fact that building and dependency management is light years ahead of older languages.

remind me again on what that has to do with either the syntax or the semantics of the underlying programming language.

Your original argument was that the ease of dependency management doesn't change programming or the act of programming. I feel it encourages a compartmentalized approach to writing programs, pulling in dependencies as needed rather than relying on a giant library like Boost. Thus it does actually change the "act of programming", which is a vague term that can mean anything.

This is not mentioning all the upsides of having a easy build system from easy learning and community standpoints.