Coming from npm, and knowing little about Go’s packaging or import system, it took a significant amount of time reading this article to understand two properties npm/Node has that seem to help alleviate the problems Go is grappling with:
Of course there are valid criticisms of both of these, some that I’m sure I’m not aware of (the author of this article is clearly more of a problem domain expert than I am) but they clearly solve a lot of problems too. The behavior of a solver in npm is a non-issue because there’s no version conflicts to solve, so you just don’t need one in the first place.
I wonder if this has contributed to npm’s small modules culture too - if you have the possibility of version conflicts then the risk of such a conflict is directly, positively correlated with the number of packages you use. But if there’s no possibility of a conflict (ignoring peer dependencies, which are more uncommon and considered an anti-pattern), then there’s no cost to having more packages in the conflict risk sense.
go has/had vendoring that is like 2.
Why isn’t it used to prevent conflicts then?