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.
Choice of tech stack is not merely a question of performance, but also portability and packaging. Self-contained, compiled static binaries are much, much more portable than shipping full script runtimes (JS/Python), dealing with the inevitable spread of runtime versions installed on everyone's machines, and dealing with the version spread of the dependencies installed separately.
> 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.
This is an argument in favor of a language like Go, arguing that the garbage collector in the runtime is inconsequential, over a language like Rust. It is not an argument for shipping a script runtime.
Yes, and clearly typescript is an established tech.
Just look at Cloudflare's wrangler cli.
Everything else is nonsense.
> This is an argument in favor of a language like Go (...)
Not really, in the sense that a myriad of alternatives would also meet the same bar,thus its stupid to frame it as "language X can do this, so language X should do it".
The bar is higher than that.
Typescript works well. Cloudflare already has a lot of experience using typescript to develop cli apps that hit their APIs.
Everyone just call down with the bike shedding. You're wasting everyone's time.
Is actually a really good example of why TS was a bad choice for Cloudflare. It made sense for their initial version, because the only programs that you could run on Cloudflare Workers were themselves JavaScript scripts, so it was a reasonable expectation that developers were already using npm/yarn/pnpm to install tools and manage dependencies.
But now, Cloudflare Workers supports containerized workloads and Python workloads. So even if your project doesn't use TS, you are still expected to set up some kind of JS toolchain for your project, just for wrangler.
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
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.