Do you include the man hours in those calculations? Because they pollute a lot between the car, the food, the electricity the computer and internet for devs consumes, etc.

Python is also getting a JIT, they’re pursuing performance on all axis.

The text editors people use to write said code will keep even more power plants online.

Especially PyCharm with its endless indexing. Have the time its key features are not available bc it has decided to go on another indexing spree. Alas that's for another thread ;)

Sometimes the right thing is writing code in a language that reaches market before runway runs out.

Ecosystem churn and exposing more issues to python contradicts this.

The whole point of using languages like python, js etc. is to not worry about whole classes of problems and intricacies.

There are modern languages with great tooling like Go, Rust or Clojure that have excellent support for safe concurrency and parallel execution etc.

And there are reliable, well established languages like Java/C# that have been doing this forever.

This. Python had a unique stance, it was different for a good reason.

The seamingly endless attempt to become more likeable to yet another subgroup of needs is not a good development. It started with static typing, it continued with async, and now we have free threading as the final draw.

That's fine for regular Python, but this doesn't convince me for multithreaded Python. Most Python modules which are optimized for performance (numpy, pytorch, pandas, and all others built on top of them) are already multithreaded and drop the GIL so you can parallelize your workload with the threading module.

If someone really needs several threads of pure python being interpreted, something is afoul imo.