I know this is going to get downvoted but what drives people to use javascript of all languages to build these fundamental pieces of tooling? We have so many better options, especially now since humans aren’t writing most of the code. It’s hard to take seriously anyone that wants to make a primarily CLI tool with heavy interactivity and parallelism requirements and decides to use a joke language that happened to luck its way into prominence because of web browsers.
What would be a better language? Most of the harness apps will be spending most of their time waiting for the models response and tool calling rather than running their code.
Languages with less opensource footprint or too verbose are at the losing side in a llm-driven world.
> most of their time waiting for the models response and tool calling rather than running their code.
You’d think that! Yet claude-code spends a very surprising amount of CPU just doing text layout work and other mysterious things, likely due to their decision to use React to build a TUI for some reason.
You either need to rebuild the harness every time you want to make a change, or a lot of deliberate effort is required to maintain an API surface for extensions, distinct from internal implementations, or you can embed an interpreter like Lua, Python, or... JavaScript. Or you could instead go the Pi route and use an interpreted language, and just load extensions into the interpreter, alongside the program itself. When one of the main goals is extensibility, the latter seems like the obvious choice.
I feel like people have forgot how extensions used to work long time ago with compiled languages. Extensions can be just dynamically loaded, (e.g. DLL from Windows world, .so from Linux). There is no need to compile the whole harness. This is also possible when using Rust, but people are just lazy.
And yes, API must be maintained for compatibility, but that is needed anyway.
Pi is extensible, and to iterate new extensions, install them, create your own, even if the agents needs to, it is much faster and easier to manage that than a compiled language I would suppose. Most of the time it's really the waiting time than anything else. If any, the "resource intensive" parts of the app could be turned into low-level extensions such as writing or reading files, maybe, but the main part of the app makes total sense. The language and ecosystem is fairly accessible as well, which serves as a further argument. Interesting choice of words when it comes to calling it "joke language" really.
I wouldn't go as far as calling it a joke language (in some ways, it's incredible), but I did come here wondering if other people felt this way. The language choice has always confused me.
On the other hand, I don't think there's anything Pi does that another language would do noticeably better from a user's perspective. Any performance complaints I have using Pi come from twiddling my thumbs waiting for Sam Altman's servers to bestow tokens upon me.
At any rate, they'll probably have Opus 6.5 and GPT-7 Galactica rewrite it in rust in a couple months...
One reason: it's really easy to have a lightning-fast dev loop when the entire running process can hot-swap almost every piece of code, when then also extends to all extensions written against the core functionality.
Which I believe is what the developer was looking to do. I personally enjoy it being JavaScript. I've had it redo some functions on the fly which to me is perfect.
TS probably has the most expressive type system of any language that I have used, and you can develop at lightning speed without fighting the borrow checker or anything else. The ability to share the exact same code across the front and back end, and encode API contracts in the type system, is a superpower for webapps built with node.
Whether an LLM writes the code or not is besides the point. What matters is that the code should be testable, and understandable. TS wins on both counts, like most sane alternatives.
I personally do not program using any language that does not have the ability to specify types.
Fair enough, I accept your opinion. Out of curiosity, which language do you think would have been better for the web? Visual Basic, TCL, and Python were the other main contenders in the mid '90s. Would you rather be working with one of those nearly every day? If not one of those, then what do you think would be best?
semiquaver · · focus · HN ↗
pezgordo · · focus · HN ↗
Languages with less opensource footprint or too verbose are at the losing side in a llm-driven world.
nicce · · focus · HN ↗
semiquaver · · focus · HN ↗
> most of their time waiting for the models response and tool calling rather than running their code.
You’d think that! Yet claude-code spends a very surprising amount of CPU just doing text layout work and other mysterious things, likely due to their decision to use React to build a TUI for some reason.
Zambyte · · focus · HN ↗
semiquaver · · focus · HN ↗
Zambyte · · focus · HN ↗
nicce · · focus · HN ↗
And yes, API must be maintained for compatibility, but that is needed anyway.
ricardobeat · · focus · HN ↗
arecsu · · focus · HN ↗
droidjj · · focus · HN ↗
On the other hand, I don't think there's anything Pi does that another language would do noticeably better from a user's perspective. Any performance complaints I have using Pi come from twiddling my thumbs waiting for Sam Altman's servers to bestow tokens upon me.
At any rate, they'll probably have Opus 6.5 and GPT-7 Galactica rewrite it in rust in a couple months...
crooked-v · · focus · HN ↗
razster · · focus · HN ↗
sieve · · focus · HN ↗
TS probably has the most expressive type system of any language that I have used, and you can develop at lightning speed without fighting the borrow checker or anything else. The ability to share the exact same code across the front and back end, and encode API contracts in the type system, is a superpower for webapps built with node.
Whether an LLM writes the code or not is besides the point. What matters is that the code should be testable, and understandable. TS wins on both counts, like most sane alternatives.
I personally do not program using any language that does not have the ability to specify types.
Maxforever · · focus · HN ↗
jazzypants · · focus · HN ↗
semiquaver · · focus · HN ↗
jazzypants · · focus · HN ↗