3 reasons why Python is much better than JS for this IMO.

1. Large built-in standard library (CSV, sqlite3, xml/json, zipfile).

2. In Python, whatever the LLM is likely to do will probably work. In JS, you have the Node / Deno split, far too many libraries that do the same thing (XMLHTTPRequest / Axios / fetch), many mutually-incompatible import syntaxes (E.G. compare tsx versus Node's native ts execution), and features like top-level await (very important for small scripts, and something that an LLM is likely to use!), which only work if you pray three times on the day of the full moon.

3. Much better ecosystem for data processing (particularly csv/pandas), partially resulting from operator overloading being a thing.

Having been doing Python for over a decade and JavaScript. I would pick Python any day of the week over JavaScript. JavaScript is beautiful, and also the most horrific programming language all at once. It still feels incomplete, there's too many oddities I've run into over the years, like checking for null, empty, undefined values is inconsistent all around because different libraries behave differently.

For historical reasons (FFI), Python has access to excellent vector / tensor mathematics (numpy / scipy / pandas / polars) and ML / AI libraries, from OpenCV to PyTorch. Hence the prevalence of Python in science and research. "Everybody knows Python".

I do like Typescript (not JS) better, because of its highly advanced type system, compared to Python's.

TS/JS is not inherently fast, it just has a good JIT compiler; Python still ships without one. Regarding security, each interpreter is about as permissive as the other, and both can be sealed off from environment pretty securely.

A big benefit of letting agents run code is they can process data without bloating their context.

LLMs are really good at writing python for data processing. I would suspect its due to Python having a really good ecosystem around this niche

And the type safety/security issues can hopefully be mitigated by ty and pyodide (already used by cf’s python workers)

https://pyodide.org/en/stable/

https://github.com/astral-sh/ty

Agreed, however AI adoption is finally putting pressure on CPython to have a JIT in the box, so there is that.

And on GPU side, the existing libraries provide DSL based JITs, thus for many scenarios the performance is not much different from C++.

Now NVidia is also on the game with the new tile based architecture, with first party support to write kernels in Python even.

Tangentially i wonder if the recent changes in the GIL will percolate to mercurial as any improvements.

Yep still using good old hg for personal repos - interop for outside project defaults to git since almost all the hg host withered.

For me it's the opposite. I'm actively looking for tools in Python because at least they're gonna be lightweight and easy for me to debug.

Really tired of every AI-related tool released as of late being a half-GB node behemoth with hundreds of library dependencies.

Or alternatively some cryptic academic Rust codebase.

Don't extrapolate

There is a ton of wheel reinvention going on right now cause everyone wants to be cool in the age of ai

Use boring tech, you'll thank me and yourself later

Which in this case means, just use regular python. Your devops team is unlikely to allow knock off python in production. TS is fine too, I mainly write Go

Python has uv, ruff, ty

I remember the time when Python was the underdog and most of AI/ML code was written in the Matlab or Lua (torch). People would roll their eyes when you told them that you were doing deep learning with Python (theano).

Can we please make as little js as possible?

Why would one drag this god forsaken abomination on server-side is beyond me.

Even effing C# nowdays can be run in script-like manner from a single file.

—

Even the latest Codex UI app is Electron. The one that is supposed to write itself with AI wonders but couldn’t manage native swiftui, winui, and qt or whatever is on linux this days.

Python has the advantage that everybody sort of knows it is bad and slow, which is an important trait for a glue language. This increases the incentive to do the right thing: call a library written in C or Fortran or something.