Cinder: Meta's internal performance-oriented production version of CPython

You see the same problem in Python with regards to correctness - it's hard to refactor Python or change a large codebase and have it keep working correctly, so huge Python projects tends to ossify.

It may be a rational solution only in the short-term, but still an objectively bad solution overall.

Awareness that organisations often end up in these problems should be considered when choosing the language for a green field project.

The community didn't have a lot of resources for a long time, and so had to prioritize: it chose to focus on python strenghts, and not compensate for weaknesses. It couldn't do both. Keeping the implementation simple was also a way to keep the project manageable on the cheap (and by cheap in mean in work hours, since the first 15 years, most core devs were just doing it for free).

Today, a lot of companies with a lot of money have much to gain to invest in python, and so we can finally have our cake and eat it too.

1. Python has a ton of C code in its libraries/stdlib, JS did not have that for the vast majority of its usage (browser). Optimizing across the FFI boundary seems unlikely to be a reasonable goal and may complicate optimization opportunity. Let's say you want to do some sort of optimization pass to make sure that `str.append` is not getting overridden - how are you going to handle native code?

2. Python is obscenely dynamic. Runtime generation of classes is not uncommon at all - for example, `@dataclass(slots=True)` creates an entirely new class.

You can overwrite methods, functions, there's heavy use of globals in libraries, no such thing as private implementations, hooks into everything, even importing code has side effects so you can't reorder or lazily import automatically, even reordering imports is unsafe in Python.

It seems really hard to optimize Python at all, and I wonder if we could ever reasonably expect to see a "V8-like" runtime, even assuming that there's funding, which I also doubt. Unless you're willing to break the language I just don't see a Python runtime overcoming these issues. Or introduce something like 'strict' where these things aren't possible.

Python has a very good set of data structures and implicit casts, that is the main reason it is popular. Compare to jagascript for example... Anyway, making python fast while keeping all those casts and data structures is very hard, Javascripts casts and data structures are bad for the programmer but very good for the interpreter so is much easier to optimize which is why it runs orders of magnitude faster.

For example, do you think that python is an appropriate language to write pylint?

* It uses an interpreter, which is slower than compiled code

* All objects carry a dict to contain arbitrary attributes - this creates huge overhead

* Even when the dict is suppressed with __slots__, all containers (all classes, even!) are untyped, so extracting any field causes dynamic dispatch

* Objects cannot be stored inline in containers

* Integers are variable-sized, and thus slower.

Of course, you might counter that one could simply make a version of Python which is compiled, where all classes have a well-defined typed layout, where some classes can be immutable for performance, containers are typed, integers are machine integers, etc. But then I'd argue you're talking about a completely different language (Julia fits this description perfectly)

It's common in science to see computer scientists implement domain-specific software with a hopelessly naive understanding of the domain, leading to biased, wrong, or misinterpreted results. Like, go to any bioinformatics conference and you will find these people.

"What do you mean I can't just use a database of clinical pathogens to make a tool that generalises to all bacteria?"