As someone who has many times dived into deep rabbit holes like this (e.g. how does JavaScript's prototype-based class work?), some effective ways to handle this is to ask follow up questions, use web search or ask for references. Deep search also helps. Often it corrects itself or takes back claims that have no basis. At the very least, it provides references that you can read yourself.

Of course, you can't really do all of that on a free plan.

That's far from ideal, but if you are motivated and care about these technical details (which you probably do), you can get pretty good results.

=====

Putting all of this aside, you can sometimes find YouTube videos on obscure channels that talk about these things. Chances are that someone who cares to make a YouTube video about these hardcore topics know what they are talking.

> Edit: Python has no JIT

In 3.14 and up you can enable JIT by setting the env var PYTHON_JIT=1

Who made this JIT? FAcebook?

Lots of people. Several people from Arm and Microsoft, various PhD students... I don't know if anyone working at Facebook worked on the JIT, maybe they did.

Facebook engineers (most notably Sam Gross) contributed a lot of the no-GIL work: https://lwn.net/Articles/939981/

Much of the initial work on the JIT came from Microsoft's Faster CPython team: https://lwn.net/Articles/1029307/

It is not that numpy bypasses public interfaces. It uses documented C APIs. V8, as far as I know, does not have that.

V8 itself might not, but, say, Node does and that doesn't torpedo performance. Was Node-API just better designed than Python's FFI?

My understanding is that Node still doesn’t give you low-level C APIs into the language itself. It gives you JavaScript APIs that call into I/O libraries (libuv basically).

Python it’s not hard to write a module in pure C that manipulates other Python objects. This means the representation of Python objects has to be stable enough for the C code. V8 does not allow that.

I haven’t tried it myself but I don’t think that’s the case. See the documentation here:

https://nodejs.org/api/n-api.html

I’ve only skimmed this, but it sure sounds like it lets you write C code that operates on JS objects. In fact, it explicitly says “APIs exposed by Node-API are generally used to create and manipulate JavaScript values.”

    > Edit: Python has no JIT

There are quite a few JITs:

JIT-compiler for Python https://pypy.org/

Python enhancement proposal for JIT in CPython https://peps.python.org/pep-0744/

And there are several JIT-compilers for various subsets of Python, usually with focus on numerical code and often with GPU support, for example

Numba https://numba.pydata.org/numba-doc/dev/user/jit.html

Taichi Lang https://github.com/taichi-dev/taichi

Per PEP 744, cpython shipped with an experimental JIT (default disabled) in 3.13. It remains experimental in 3.14.

See https://docs.python.org/3/whatsnew/3.13.html#an-experimental...

If we are being very pedantic, languages don't have "speed", only implementations do.

Of course in the real life there are de facto implementations and language features give way to better/worse tradeoffs.

With that out of the way, Python is basically the de facto glue language. It is very often used to provide a scripting API over lower level C libraries. To be ergonomic in this function, CPython (the major implementation) exposed some internal details of its execution model, which C libraries can reach into. This makes it very hard to make more aggressive optimizations, as one example a C library can just increase/decrease the reference count of an object. Another design decision (that got some discussion recently) is the GIL (global interpreter lock) that makes python much less competitive than something like Java. (JS also does a single thread of execution, though there are ways around it).

JS has a different use case, so access to the C world doesn't impose such restrictions on it.

Both you and the grandparent comment are correct. The implementation is slow because the API that it exposes is so leaky that implementation changes (for example a tracing garbage collector) are impossible to implement without changing the API, and the API cannot easily change because of the dependence or the ecosystem on it (e.g. numpy)

For what it's worth, I really don't get the downvotes. I think it is an interesting question, and it brought interesting answers.

No clue if that's the reason for the downvotes, but maybe next time don't mention ChatGPT and just formulate this as "From what I read, [...]".