I will never recommend Python outside of a small team. It is organizational molasses. My current company has multiple teams striving to keep our Python tech stack serving our growing technical and organizational scale.

I have fixed this in two companies in no small part with migrating to Go. I am on my third.

I'm curios if you can spot a pattern in the platform (win/osx/linux), type of project, or is it all over the place?

My own experience with Python boils down to creating a virtualenv, installing the deps, setting up configuration (or just copying it from somewhere) and creating a database, and I'm off to the races. The only exception in recent memory was when a project had two dozen microservices, half of the codebase was on private package repository, and we used Poetry. The combo required somewhat more involved setup. That said, IIRC all the projects had fully pinned package versions (package==x.y.z).

In contrast, every time I touch something in JS land I get the same experience you described for Python. On one project we literally copied node_modules across machines (including servers), because it was unbounded amount of time trying to do a full reinstall. Anecdotally, amount of churn in JS is much higher, and the maintenance load increases proportionally.

Usually it's something like:

- have a project in JS with some dependency X that's no longer on the bleeding edge, but works nice

- want to depend on a new package Y for some new feature

- the new package Y depends on a library Z that's higher than what the other dependency (X) can work with

- try to update the original dependency (X)

- wailing, gnashing of teeth, and considering the switch to agriculture instead

In my experience, if you're not closely tracking the bleeding edge, upgrading packages and updating your code accordingly, your JS developer experience will be abysmal.

Agree on the CD part, especially the fragility and more manual work than if the deploy is some manually driven (semi-)automated process.

So there is virtualenv, built in, but... if there is a venv directory, Python doesn't just use it.

Like you have app.py, and you python app.py, that doesn't run it with the venv python. This leads to all sorts of problems with scripts that assume they're running under venv. Which means you probably want to write a script that sources venv just so you don't forget, but if you place it in the same directory you may forget you need to call the script, so you probably want to add an extra directory to hide all the python code so you only see the shell script that you need to run to properly setup the environment to run the python code. Or just use an IDE.

Just "pip install." But pip isn't installed and ensure pip doesn't work? What do I even do then?

I recall downloading a project that required a library that wasn't available for the newest version of python, so when you tried to install the requirements pip wouldn't find it. I discovered this, naturally, because I updated my operating system so the python version changed which means the project that used to work stopped working! What is the solution for installing multiple python versions side by side? Hint: it's not an official project by the Python organization but something you can find on github.

Do you mind sharing why do you think this happens ? Although I never worked professionally with python, this sentiment matches with my experiences as a user. So I don't have a lot of context why this is the case.

Some siblings in this thread provided some explanations that mostly boils down to 'bad tooling' in one form or another. But this doesn't feel right.

In my opinion if it was just bad tooling this problem would be solved by now.

1. Extremely difficult to setup the code base, because of dependency spaghetti 2. Lot of breaking changes across different libraries, making maintenance not so easy.

Easiest projects to maintain were written on Go, Java, Ruby,

I got a new Chromebook from work, and had VSCode+Docker running an existing Postgres+Django+etc dev environment in literally 15 minutes. I was shocked. Devcontainers are magic, and poor Python DX is a skill issue.

It's not an accident -- reading through the emacs-devel mailing list, it's easy to see how much effort the maintainers pour into backward compatibility. It's one of Emacs' unspoken guiding principles[1].

At the same time, it's not that surprising either. Emacs does not have other objectives that more modern languages/ecosystems do: no revenue or growth targets, corporations or VCs breathing down its neck, or a mandate to be "modern". Its most vocal and experienced users, who are also its volunteer maintainers, decide what its priorities should be. Since they've been using it for decades, backward compatibility is high on the list.

[1]: It's "spoken" guiding principles being to further the goals of the GNU project.

My initial reaction was that it was a list of fairly complex things, but they are not necessarily complex to implement, even if people commonly over-complicate a couple of those things or make them a pain for other developers to setup, which seems to be part of the point.