Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a first party hacky workaround
So, ultimately, all people are saying when they knock Go's package management is that they don't like how it works. That's fine, I don't like how all sorts of things work. But "nothing" is false, and "hacky" is so subjective as to be practically worthless. Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language, and, to me at least, it follows obviously that they solved package management to some level of the community's satisfaction, because languages without package management aren't successful.
If we wanted to hash out the pros and cons of different package management strategies, that's all the thread will be: just hundreds of back-and-forth messages about package management. It's a big topic.
When I wrote Go, the official language policy is that you do not need versioning and should not make breaking changes. Throw everything into a vendor/ if you must. For me, that kind of stance on package management definitely warrants attention.
There are lots of things I don't like about NPM. But imagine claiming that Node doesn't have real package management. You can't even write a for-loop in Node without a package. Go isn't quite that far gone, but it's pretty hard to write idiomatic Go of any significance with zero packages.
But they really did launch with no solution and take a fairly long time to figure it out.
The same can't be said of slightly older languages like C#, Java, or python. Perl, for all its foibles, was probably the first language with a more modern package management system (CPAN).
The problem is if you don't consider these things in your initial design, the solution you end up with later tend to be worse.