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.
semiquaver · · focus · HN ↗
pezgordo · · focus · HN ↗
Languages with less opensource footprint or too verbose are at the losing side in a llm-driven world.
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 ↗