GOPATH is luckily soon dead.
The last few years I cannot help but feel they were very close to making 2 and 3 play nice together, but the idea ironically lost traction because of how much Python 3 adoption had accelerated.
If Go is successful for any significant period of time, that will change.
I think Python’s packaging story is a bummer in part because Python leans so hard on C which doesn’t have a standard build system or a sane approach to building or packaging.
Sure, and when it has been “pretty established” for a couple of decades, it’ll have a chance to have the community weight of important legacy projects that Python has.
First of all, it’s not much of a consolation to users that the packaging and performance are bad “because the language is old”, and secondly Python had already had half a dozen significant changes to its packaging format and ecosystem by the time it was Go’s age (distutils, cheeseshop/pypi, PEP241, setuptools, eggs, easy_install, etc).
Note that by this time, Python’s package management was far more complex than Go’s and it was also far more painful (and indeed, still is far more painful). Note that Go deprecated GOPATH when the language was already 9 years old, at a point when it was quite a lot older and more widely used than Python’s myriad package formats which are still supported today.
We can say “No fair! Go has the benefit of hindsight!” and true enough, but again as a user, I don’t much care—I just want the tool that’s going to solve my problem with the least headache.
And this isn’t even touching on the Python 2-3 saga, which began when Python 2 was merely 8 years old and lasted for more than a decade. If you want to argue that we should use the Python 1.0 release date for our comparison, then fine—call me in ~4 years if the Go ecosystem is on the precipice of a suite of breaking changes which constitute an existential crisis. My money says that wonky happen.
No, its a an argument that applies to the ease of making disruptive changes to languages with less legacy in the ecosystem (age is a factor, but not the only one; its also a reason why Ruby, which was a similar age with the disruptive 1.8 to 1.9 transition had an easier time than Python did with 2 -> 3).
It doesn't apply to all criticism, or even to “older languages” generally (at least not equally, though survivorship bias means it is likely at least somewhat applicable to older languages that it is interesting to discuss in the first place.)