1. it's built for async
2. runs everywhere
3. interpreted, making it fast to iterate on
4. decent performance
5. most popular language, llms are decent at writing it
An additional benefit of interpreted, I think, is to make plugins easier to distribute and incorporate. With a compiled language you’d need message passing or something.
JVM apparently has the disadvantage that nobody under the age of 40 wants to touch it anymore. I admit I haven't worked in it in 20 years, but I do think it's a marvel of engineering and unfairly maligned. It used to be my career but I wanted to be closer to the metal.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
That actually don't like you're describing Python. I've been working on a couple JS/TS projects and it's like the models I use (Claude Sonnet and DeepSeek v4 Flash) continually struggle to do coherent work; I have to always keep close watch to reduce sloppiness. I go to Python and it's smooth sailing with minimal prompting (and reduced token burn) for acceptable outcomes.
aren't 3 and 4 a tradeoff though? Yes you have 3 but "decent performance" cannot be an extaled value as compared to "runs everywhere". If its used as a counter balance to 3 then it shouldn't be its own unique point basically saying 4 is true despite 3 in this case.
decent performance, lol! compared to what? a shell script? "i'll only take up 200MB of disk and 4GB of RAM to output flickering text on a terminal. boy this is high performance"
fast iteration is for POCs. once you have the app built and working, you need performance and stability much more than fast iteration
Probably for the ease of coding extensions — which strikes me as outdated thinking: if it’s open source and you’re outsourcing the coding to LLMs, why not use a compiled, safe language?
There’s an interesting counter example for DeepSeek called CodeWhale, though:
I don’t think so. The ChatGPT app was, which is the “Classic” app now. The Codex app that they’re carrying forward is an Electron app and if you forget to quit it before you walk away it’ll make even your M5 Max unresponsive eventually. Sad days.
I'm not sure why specifically Javascript instead of something like Python or other options, but using an interpreted environment minimizes the friction for implementing extension systems, which are an important feature in AI harnesses.
Python basically requires containers unless you are OK with it bit-rotting every six months or so. At least, this used to be the case for trivial python, and recently was the case for stuff that uses cuda.
I stopped paying attention the third time they redefined matrix arithmetic semantics. That happened to be around the 100th time I was sent a script and it only ran on the author’s machine. Maybe they will fix it some day. When they do, I will not believe it.
In contrast, TS has a much nicer type system and better async support. It runs well on web, mobile, desktop and server. Yes, sometimes you have to ship node.js or a whole web browser, but the tooling for that is slightly less insane than the analogous tooling for python.
Its language interoperability story is slightly nicer too (invoke native code, or use wasm). It’s UI story is much, much better since it reuses all the web stuff.
Pip practically invented the supply chain attack; npm perfected it. That’s probably a draw.
Of course, if you care about performance, then other choices make more sense. If you’re training a model then python probably still wins, but very few customers have a $1M+ machine.
`uv` helps but it's new, and I don't think it has the same mindshare yet on "I just globally want to install this thing that needs an interpreter/runtime", so Python probably just doesn't come first to mind.
I'd put it on this. In my experience Python is fine for scripting your own machine but an obnoxious platform to distribute code on. It's very fragile to version changes, in both directions; I don't know how many things I've seen that only run on 3.10, not 3.9 or 3.11. Its packaging system is global by default which only compounds this because everything needs a specific version but they're all dumped in the same place. And it tends to have a lot of native code as dependencies, leading to all the issues of needing to either have the right build environment or a runtime environment that's already been built for.
i also got quite a lot of requests to provide the code in non-golfed form to make the implementation more approachable and idiomatic in each language (will do!)
> But for CLI, it never made sense to me. Especially when Python and Go exist.
But why? Not saying node is better, just want to know where you are coming from for my own knowledge.
Bc I would have picked typescript + node too. It has types (where python just has type hints) and a lot of developers know it already (where go is more niche).
Because:
1. The first significant agentic harness was made by Anthropic.
2. One of the most senior developers of client-side software at Anthropic is Felix Rieseberg, one of the original creators of Electron. [1]
3. After Claude Code blew up, everyone else copied Anthropic.
---
1: https://daringfireball.net/2026/07/claudes_criminally_bad_ma...
1. it's built for async 2. runs everywhere 3. interpreted, making it fast to iterate on 4. decent performance 5. most popular language, llms are decent at writing it
An additional benefit of interpreted, I think, is to make plugins easier to distribute and incorporate. With a compiled language you’d need message passing or something.
dynamic linking was invented pretty long time ago
1 reply →
JVM has real and virtual threads and arguably just as good if not better on all these points.
(I actually have/am writing a harness in Java fwiw, but mostly as a hobby/experimentation)
JVM apparently has the disadvantage that nobody under the age of 40 wants to touch it anymore. I admit I haven't worked in it in 20 years, but I do think it's a marvel of engineering and unfairly maligned. It used to be my career but I wanted to be closer to the metal.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
4 replies →
I hate nodejs and the npm ecosystem more than most, but Java, really?
But have you considered that java is gross and nodejs is sexy?
That actually don't like you're describing Python. I've been working on a couple JS/TS projects and it's like the models I use (Claude Sonnet and DeepSeek v4 Flash) continually struggle to do coherent work; I have to always keep close watch to reduce sloppiness. I go to Python and it's smooth sailing with minimal prompting (and reduced token burn) for acceptable outcomes.
aren't 3 and 4 a tradeoff though? Yes you have 3 but "decent performance" cannot be an extaled value as compared to "runs everywhere". If its used as a counter balance to 3 then it shouldn't be its own unique point basically saying 4 is true despite 3 in this case.
when you're waiting for network or LLM inference the raw performance doesn't matter at all
6 replies →
decent performance, lol! compared to what? a shell script? "i'll only take up 200MB of disk and 4GB of RAM to output flickering text on a terminal. boy this is high performance"
fast iteration is for POCs. once you have the app built and working, you need performance and stability much more than fast iteration
Probably for the ease of coding extensions — which strikes me as outdated thinking: if it’s open source and you’re outsourcing the coding to LLMs, why not use a compiled, safe language?
There’s an interesting counter example for DeepSeek called CodeWhale, though:
https://github.com/Hmbown/CodeWhale
Also isn't OpenAI's Codex written in Rust?
I don’t think so. The ChatGPT app was, which is the “Classic” app now. The Codex app that they’re carrying forward is an Electron app and if you forget to quit it before you walk away it’ll make even your M5 Max unresponsive eventually. Sad days.
1 reply →
Codex, Kiro, Grok Build. Pi has a clone in Rust too.
I don’t think so it’s an npm package iirc
2 replies →
I'm not sure why specifically Javascript instead of something like Python or other options, but using an interpreted environment minimizes the friction for implementing extension systems, which are an important feature in AI harnesses.
Python basically requires containers unless you are OK with it bit-rotting every six months or so. At least, this used to be the case for trivial python, and recently was the case for stuff that uses cuda.
I stopped paying attention the third time they redefined matrix arithmetic semantics. That happened to be around the 100th time I was sent a script and it only ran on the author’s machine. Maybe they will fix it some day. When they do, I will not believe it.
In contrast, TS has a much nicer type system and better async support. It runs well on web, mobile, desktop and server. Yes, sometimes you have to ship node.js or a whole web browser, but the tooling for that is slightly less insane than the analogous tooling for python.
Its language interoperability story is slightly nicer too (invoke native code, or use wasm). It’s UI story is much, much better since it reuses all the web stuff.
Pip practically invented the supply chain attack; npm perfected it. That’s probably a draw.
Of course, if you care about performance, then other choices make more sense. If you’re training a model then python probably still wins, but very few customers have a $1M+ machine.
`uv` helps but it's new, and I don't think it has the same mindshare yet on "I just globally want to install this thing that needs an interpreter/runtime", so Python probably just doesn't come first to mind.
I'd put it on this. In my experience Python is fine for scripting your own machine but an obnoxious platform to distribute code on. It's very fragile to version changes, in both directions; I don't know how many things I've seen that only run on 3.10, not 3.9 or 3.11. Its packaging system is global by default which only compounds this because everything needs a specific version but they're all dumped in the same place. And it tends to have a lot of native code as dependencies, leading to all the issues of needing to either have the right build environment or a runtime environment that's already been built for.
codex is written in rust fwiw
smol has implementations in Go, Python, Clojure, PHP
https://github.com/smol-env/smol
out of the box an agent only needs to be able to do http requests and call tools (which might again be just http requests or shelling out)
there is no inherent reason for why an agent has to be in JavaScript or Typescript
but they are popular languages and come with runtimes and libraries for http requests, steaming, TUI (terminal ui) and so on which can help
I'm interested in this but why those four separate languages
Edit: okay I read the code, it's actually four separate implementations
Yes it's separate implementations of the same minimal idea
I'm currently working on more 'feature-full' but still minimal variants
e.g. a python variant with automatic compaction + truncation of sh output
https://x.com/__tosh/status/2087606344035479632
i also got quite a lot of requests to provide the code in non-golfed form to make the implementation more approachable and idiomatic in each language (will do!)
TypeScript is great and its ecosystem is easy to work within.
Because that hammer is their only tool!
I gotta same problem.
Might be easier to do cross platform.
npm as a distribution tool works well and typescript has types.
Any reason why it should not be written in nodejs?
I always thought nodejs was a weird choice for CLI tools.
For web stuff, sure.
But for CLI, it never made sense to me. Especially when Python and Go exist.
> But for CLI, it never made sense to me. Especially when Python and Go exist.
But why? Not saying node is better, just want to know where you are coming from for my own knowledge.
Bc I would have picked typescript + node too. It has types (where python just has type hints) and a lot of developers know it already (where go is more niche).
1 reply →
Nothing better for UI than React. Electron/tauri or node kinda falls from it.
Skill issue. Their models don't work for serious programming so everyone just copies Electron apps from each other.