> [...], written in TypeScript and accelerated with C++ bindings to BLAS and LAPACK

C++ addons for Node.js are not part of the JavaScript runtime.

But it still blocks event loop ?

Native bindings can use libuv to offboard work to other threads and then re trigger the JS execution when it completes.

This is how a lot of the native node libraries work under the hood to allow parallel IO operations! It’s also an incredibly powerful performance optimisation tool in more complex, scale out NodeJS deployments.

So in theory, if we ported python libraries into JS, the performance could be better than Python ?

At work we do some pretty significant parallelised computation (using Node and Rust) and that has equivalent performance to a relevant python based library.

There are nuances to how data enters and exits the VM runtime which means I couldn’t say with confidence if performance would be better or worse in the general case - but either direction is at least technically viable.

i was thinking about that, seems like a good deal overall with limited overhead.

Python bindings for native libraries would still be the same, they are the same native libraries, while pure Python code would speed up thanks to JavaScript runtimes having JITs.

Just like Python, but at least has a JIT on the box.

Arguably better async primitives too. Python's main advantage at this point feels like a stronger ecosystem of packages calling into native code (eg numpy et al mostly call optimized C routines). If Typescript adds more of those libraries (like this one), then I could see it gaining a lot of adoption.

I think Bun (which has typescript embedded but written in zig) would be a great place to experiment.

I could see it adding some tensor types that drop into zig code that uses webgpu bindings. And add some operator overloading so you could just add t1 + t2 etc.