> Making all of these overlapping API calls in a performative, reliable way is a challenge.
Pythons asyncio is pretty hard to beat. For non-cpu intensive tasks, I find it a pleasure to work with. Goroutines can still have race conditions.
> Originally, we wrote the CLI in Python, but trying to distribute it across platforms proved to be too difficult
Sure, I get that go can cross-compile. But what makes python hard? Python works on every platform, and distributing is just a "pip install" and "pip install -u" 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"
I was the original author of the awseb cli and we found that pip install was significantly less of a hurdle than a go binary and decided to do it in Python instead. If a user on windows has a hard time installing python and pip, telling them to drop a binary and change their path isnt going to be any easier.
> 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).
I was yelled at a few times for not using package and environment management tools (Conda, etc). So, when working with Python it is not just a "pip install" anymore
We thought similarly to you about the relative ease of "pip install"—which is why we originally wrote the CLI in Python. Pretty immediately, however, we heard back from users who experienced friction. With the Go binary, we're able to share a one line bash command that users on Mac/Linux (Windows coming soon) can run to install the Cortex CLI, which removed the need for us to instruct users on how to configure their local environments. We've found that this one line install works better for our users: https://www.cortex.dev/install
Also, when we had the Python CLI, some of our users complained that in their CI systems which ran `cortex deploy`, they didn’t need Python/Pip in their images, and installing them was inconvenient
If you are having them bash a shell script, that shell script could install a python package as well. If your users like the bash install, I dont think rewriting in go was required for that. I guess I dont understand why this is any easier. For "cross platform" windows users dont even have bash.
Pythons asyncio is pretty hard to beat. For non-cpu intensive tasks, I find it a pleasure to work with. Goroutines can still have race conditions.
> Originally, we wrote the CLI in Python, but trying to distribute it across platforms proved to be too difficult
Sure, I get that go can cross-compile. But what makes python hard? Python works on every platform, and distributing is just a "pip install" and "pip install -u" 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"
I was the original author of the awseb cli and we found that pip install was significantly less of a hurdle than a go binary and decided to do it in Python instead. If a user on windows has a hard time installing python and pip, telling them to drop a binary and change their path isnt going to be any easier.