> I don't get why people object to performance work on languages not intended for performance.

You're right, this objection is not relevant in general.

But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free.

This trade of makes the point about the language choice relevant.

> I don't get why people object to performance work on languages not intended for performance

My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it.

I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)

As someone who learned on python (many years ago), I think the balance of being allowed to shoot myself in the foot, while only having to learn complexity when complex concepts came up, was a good combination rather than a bad one. Trying to learn C++ and Java before, having to type everything was an impedement. On python, you find out that types still matter when you try to add a string to an integer, for example. The moment the type matters to you is when you need to dig into those details. I'm not sure I would have the career I do if it hadn't been around to be the one language that fit my 16-year old brain.

You don't have to compete with C++. If switching the interpreter allows you to save 20% server costs at ~0 development cost that's a no-brainer. Rewriting your stuff in C++ might allow you to save 95% of your server costs, but development cost is a lot higher.

>I don't get why people object to performance work on languages not intended for performance.

It's simple, really. They're concerned about the trade-offs.

If it's in a fork that you can pretend doesn't exist if you don't want it... what is the trade-off?

A fragmented ecosystem, incompatibilities, etc.

And more importantly, your original question isn't asking about forks, specifically. It was asking why someone might oppose performance work.

> incompatibilities, etc

But it's compatible. It's a drop-in replacement.

Serious question: do you have experience with “drop in replacements” for reference implementations? They’re rarely 100% compatible. Especially when the reference implementation isn’t formally specified.

Moreover, you continue to cherry pick, neglecting the other arguments you’ve been presented. It sounds like you’ve already made up your mind about this.

Other arguments are ‘it’s not worth it’ or ‘it’s not likely to succeed’ but nobody is making you do the work!

Hmm no, they’re really not. I’ll leave you to reread the tread.

> I don't get why people object to performance work on languages not intended for performance.

Presumably because they see it as effort that could be better applied elsewhere.

I don't know that I agree, but I can understand the viewpoint.

People object to changes in requirements and implementations that they don't control and don't perceive as being beneficial to their use case.

But it's a fork. And what do you mean by 'requirements'? It's compatible. Forget it exists if you don't want it.