As someone who has thought Go was a poor choice for almost any project for a long time and argued that many times, I used to come up against the argument that G

As someone who has thought Go was a poor choice for almost any project for a long time and argued that many times, I used to come up against the argument that Go package management was superior to other languages. Six months ago I said: > Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems. > With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go. > You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option. > I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries. > If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight. And in a different post: > give it a decade and Go packaging will be just as miserable as packaging in any other language. I've been coming up against that argument a lot less lately. It looks like my prediction is coming true a bit ahead of schedule.