> Python works on every platform, and distributing is just a "pip install" and "pip install -u"
Until you have a dependency which has a C dependency (like a crypto framework, SQL connector, etc). Suddenly you need an entire compiler toolchain, dev dependencies, all the library headers, and a decent amount of time. Also the errors thrown when these compile steps fail are anything but helpful for new users. If you are lucky there is already a wheel for your platform/arch.
> Surely thats easier than "Download the correct binary for the platform, unzip it, change permissions, add it to your path, then do it all over again for every update"
This is trivial to automate using a script and has a ton less failure modes to deal with than Pip would have (do you have the correct Python version?, is there a compiler installed for C modules?, etc).
> Until you have a dependency which has a C dependency (like a crypto framework, SQL connector, etc).
but... that's not a python problem.
every time people say they are having a hard time installing a python module, it's almost always a non-pure python module. it has an extension in c or c++. if that tells us anything, it's that mixing c and c++ makes software hard to install...
a fairer comparison with go here is with a go package that has extensions or bindings written in another language.
Sure, but the most popular Python connectors for MySQL and PostgreSQL both utilize C or C++ extensions, whereas the equivalent connectors for Go are both written in pure Go. Even if it's not a problem with the language in its purest form, it is a problem with the ecosystem.
It is a Python problem because we praise Python for how portable it is, that it binds with every C library out there to provide the functionality we need at the performance we want and how easy it is to install with Pip. But then forget all the problems people get in during installing.
A fairer comparison would be comparing the ease of how to create and install a cross platform Go binary compared to how to distribute a Python application as a single package/pseudo-binary (I've been down that rabbithole and many others with Python packages in the past 15 years).
Until you have a dependency which has a C dependency (like a crypto framework, SQL connector, etc). Suddenly you need an entire compiler toolchain, dev dependencies, all the library headers, and a decent amount of time. Also the errors thrown when these compile steps fail are anything but helpful for new users. If you are lucky there is already a wheel for your platform/arch.
> Surely thats easier than "Download the correct binary for the platform, unzip it, change permissions, add it to your path, then do it all over again for every update"
This is trivial to automate using a script and has a ton less failure modes to deal with than Pip would have (do you have the correct Python version?, is there a compiler installed for C modules?, etc).