I don't understand why this is written in Typescript. This is a great example of how agents can write code (I'm sure they wrote `cf`), yet having fundamental computer science knowledge is still critical. Do not force your users to manage the dependencies of your cli. Do write your cli in a compiled language. Understand the reason for those decisions and tell your agents to use the correct architecture.
No it is exactly right mode for modern tech companies:
1) If it runs on my dime and my infrastructure I will optimize the hell out using most cleverly written Rust and what not and gloat about engineering prowess.
2) If it runs on users computers well then, we have carefully evaluated our strategic direction and come to conclusion that JS/TS/Electron option is the best way to go.
There's also a (maybe more minor but still interesting) explanation. On a server, you know quite precisely your load and you want to be able to causally trace bottlenecks, which is simpler with AOT compiled programs. On users' machines, they may not give you full telemetry and may use your system in quite variable ways. So V8 comes in quite nicely and optimises hot paths on workload it observes on each users system.
Is this sarcasm? We’re talking about a CLI. The fancy JIT system will collect data from one single operation and then promptly forget everything it learned and discard all those shiny optimized instruction sequences before the next operation.
For example are workloads for which Java performs very, very well. CLI tools that do one operation and return are not examples of these workloads. v8 is plausibly less bad because v8 is also optimized for short-running scripts, but that just means less outrageously slow, not that it will be remotely competitive with native code.
This is precisely why this blend of comments is insane.
All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
Pretty much any choice of tech stack will work well. This is not rocket science. It's pointless to talk about optimized solutions. It's a complete waste of time.
> Pretty much any choice of tech stack will work well.
No, it won't.
I just tested gcloud (brand new install, modern "cli" version, not the old "sdk" version, although the "sdk" version was every bit as bad).
With a warm cache:
$ time gcloud &>/dev/null
real 0m1.215s
user 0m0.954s
sys 0m0.243s
It doesn't get faster if I give it a valid action instead of just getting the overview help screen. This is so slow that a remote LLM can get bored!
A CLI should be snappy. A CLI targeted at agents should be even snappier. We're note talking about massive throughput here -- we're talking about the latency added to a tool call for the mere fact that the tool call invokes the CLI. Google should be targeting two orders of magnitude of improvement here
That's fine if all you want to do is put together a nonsensical apples to oranges comparison.
If you actually want to take a look at what kind of cli app Cloudflare can put together, you'd look at the likes of wrangler.
I mean, I'm sure it takes a couple of minutes to find a notable cli app written in your language of choice with is riddled with problems. Don't you agree? Would that serve as proof your language of choice is bad?
Having said that, you should take a look at what kinds of tests you are doing and what kind of values you're seeing. Any http request is expected to take ~200ms to execute, and any app that does any kind of auth verification will do a pair of those at app start. This is before the app does anything useful. Therefore this means you are trying to nitpick over milliseconds in domains where latency alone will be an order of magnitude or two greater than the values you are holding onto as meaningful.
Why do you think the likes of nodejs dominates backend development? It's surely not because of isomorphic JavaScript, it's something else.
slowin · · focus · HN ↗
geodel · · focus · HN ↗
1) If it runs on my dime and my infrastructure I will optimize the hell out using most cleverly written Rust and what not and gloat about engineering prowess.
2) If it runs on users computers well then, we have carefully evaluated our strategic direction and come to conclusion that JS/TS/Electron option is the best way to go.
gobdovan · · focus · HN ↗
amluto · · focus · HN ↗
For example are workloads for which Java performs very, very well. CLI tools that do one operation and return are not examples of these workloads. v8 is plausibly less bad because v8 is also optimized for short-running scripts, but that just means less outrageously slow, not that it will be remotely competitive with native code.
locknitpicker · · focus · HN ↗
This is precisely why this blend of comments is insane.
All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
Pretty much any choice of tech stack will work well. This is not rocket science. It's pointless to talk about optimized solutions. It's a complete waste of time.
amluto · · focus · HN ↗
No, it won't.
I just tested gcloud (brand new install, modern "cli" version, not the old "sdk" version, although the "sdk" version was every bit as bad).
With a warm cache:
It doesn't get faster if I give it a valid action instead of just getting the overview help screen. This is so slow that a remote LLM can get bored!A CLI should be snappy. A CLI targeted at agents should be even snappier. We're note talking about massive throughput here -- we're talking about the latency added to a tool call for the mere fact that the tool call invokes the CLI. Google should be targeting two orders of magnitude of improvement here
locknitpicker · · focus · HN ↗
That's fine if all you want to do is put together a nonsensical apples to oranges comparison.
If you actually want to take a look at what kind of cli app Cloudflare can put together, you'd look at the likes of wrangler.
I mean, I'm sure it takes a couple of minutes to find a notable cli app written in your language of choice with is riddled with problems. Don't you agree? Would that serve as proof your language of choice is bad?
Having said that, you should take a look at what kinds of tests you are doing and what kind of values you're seeing. Any http request is expected to take ~200ms to execute, and any app that does any kind of auth verification will do a pair of those at app start. This is before the app does anything useful. Therefore this means you are trying to nitpick over milliseconds in domains where latency alone will be an order of magnitude or two greater than the values you are holding onto as meaningful.
Why do you think the likes of nodejs dominates backend development? It's surely not because of isomorphic JavaScript, it's something else.