I'm Lua fanboy, but I've to admit, that I'm missing clean deployments and upgrades with virtualenv and pypi available in Pyhton. I've never had any issue so far, am I being just lucky bastard? It has been like that for many years already.

> Ruby has better tooling libraries

On the other hand, I've honest to maintain one Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance :-)

Well that is your problem right there - don't drink in advance, drink afterwards to try delete the traumatic experience from your memory!

My solution was to docker all the things. It made my life so much better; you could simultaneously run multiple services on the same box without awful fragile hacks.

There's a few python libraries out there which just crash the entire stack, like Python-Mysql (or was it PyMysql, or one of the other very similarly named libraries?). And I might be biased, but talking to a mysql-db shouldn't be hard.

>On the other hand, I've honest to maintain one Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance :-)

I rather mean tools like rake as a task-runner, guard, rubocop, thor as a templating system, rspec, chef as config management, kitchen, food-critic, sinatra for easy web services. It's a whole bunch of stable tools and tooling libraries (and they are integrating with each other).

When are dynamic languages finally going to learn from these problems and fix them? Smalltalkers were making these exact complaints to me in person in the 90's and I know they predated my involvement by a lot.

What if someone created a Smalltalk-like uber-debugging-godlike-power-over-the-runtime alternative compiler target for Golang? Then you'd have all the good parts of dynamic languages with the dead-simple distribution model of Golang.

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.

I stand by what I said: give it a decade and Go packaging will be just as miserable as packaging in any other language.