> It's not a problem in languages that come with a package manager, or at least promote a specific one to handle dependencies.
No. It is pretty much only a problem in languages with a package manager. Languages without the notion of package versioning don't run into the issue of needing to have a notion of what a version is, clearly. A package manager just helps automatically enforce versioning, it does zero to help you figure out what the correct version is.
Yes, not coming with versioning and a package manager comes with its own disadvantages and pain, no doubt. And we can surely debate which pain outweighs or is worse. But claiming that package managers would solve this problem just isn't true (I wrote the article when the whole "SemVer and package manager for go" debate was taking off and I tried to come up with a better approach).
> It's only a problem in languages where developers thinks "you don't need that". There is this weird belief in the Go community that Go is a miraculous language where good programming practices don't apply because Go magically make them irrelevant.
Can you source that? I am one of the most vocal opponents of package managers and versioning in go, but this contradicts everything I believe about it. My believes aren't, that go doesn't need it, but that a) it comes with its own set of problems, that b) those outweigh most of the benefits, IMO and c) that by considering and discussing it carefully, we might be able to come up with an actually innovative new solution to the problems.
Nowhere do I claim that go doesn't have those problems, on the contrary. I'm just arguing that, traditionally, go is a language that prefers doing things right over doing things like they were always done.
No. It is pretty much only a problem in languages with a package manager. Languages without the notion of package versioning don't run into the issue of needing to have a notion of what a version is, clearly. A package manager just helps automatically enforce versioning, it does zero to help you figure out what the correct version is.
Yes, not coming with versioning and a package manager comes with its own disadvantages and pain, no doubt. And we can surely debate which pain outweighs or is worse. But claiming that package managers would solve this problem just isn't true (I wrote the article when the whole "SemVer and package manager for go" debate was taking off and I tried to come up with a better approach).
> It's only a problem in languages where developers thinks "you don't need that". There is this weird belief in the Go community that Go is a miraculous language where good programming practices don't apply because Go magically make them irrelevant.
Can you source that? I am one of the most vocal opponents of package managers and versioning in go, but this contradicts everything I believe about it. My believes aren't, that go doesn't need it, but that a) it comes with its own set of problems, that b) those outweigh most of the benefits, IMO and c) that by considering and discussing it carefully, we might be able to come up with an actually innovative new solution to the problems.
Nowhere do I claim that go doesn't have those problems, on the contrary. I'm just arguing that, traditionally, go is a language that prefers doing things right over doing things like they were always done.