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.
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.
> Choice of tech stack is not merely a question of performance, but also portability and packaging.
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.
> 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.
When you have buggy software like Claude Code where they literally had to buy the company that made the software and then machine translate it to Rust just to make it fast enough, it's not "a complete waste of time." Somehow people can turn even CLIs into unoptimized garbage.
I don’t agree with that at all, there is a high startup cost to languages like Java and to a lesser extent, JS. Java won’t do anything at all for about 60ms last I measured. This is noticeable to users. JS does better which is why you still see some JS based CLIs. But languages like Go and Rust really are much better for this, they don’t require a huge VM installed on your system and start up instantly. I can also recommend Common Lisp as it has an insanely low startup latency. Ship a single file binary without dependencies please.
I mean it is the reason they would like to give. Should we accept it though as their core motivation vis-a-vis it is most convenient and low effort for them so they will do it.
My read is that it's generally the teams that have been assigned to build a certain product that end up choosing the architecture that it runs on. So when we see TypeScript involved in TUI and CLI applications, most of it is just a repurposing of skill sets from that domain into the terminal. In an organization like Cloudflare, I expect that the developers who don't specialize in TypeScript are working on far more important problems.
Whether it was deliberate or not, I do not think it's a good choice. When agents can write in any language, there's no reason to pick the wrong tool for the job. At this point Javascript/Typescript belongs only in the browser. It's the suboptimal choice for every other environment. Especially for a command line tool. Even if the back-end is written in Typescript (also not the best choice imho), the clients need not be in the same language.
Various agent tools (including current versions of codex-rs, which is otherwise a normal Rust program) make effective use of JavaScript/TypeScript for “code mode”. I actually think it’s an excellent choice for this use case. (I think that a less weird language with otherwise similar optimizers and tooling would be even better, but JS/TypeScript is what we have.)
What would even be a good alternative? The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.
> The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.
JS as a tech stack breaks your "fully safe" constraint (unless you are talking about running a CLI JS application without using npm...)
In this particular instance, I mean JS-the-language, not JS-the-ecosystem with browser and/or npm-style APIs.
codex-rs's code-mode-runtime uses plain V8 and gives it limited capabilities. (It gives it a very strange set of capabilities, but the point is that a program can grant specified capabilities to a JS script that it hosts, and the JS script can use those capabilities and nothing else.)
I suppose I should have added Lisp-like langauges to my list, although those don't have the kind of static type checking that TypeScript can offer.
Typescript and the npm/JS ecosystem may be complex, but you don’t need AGI to figure out how to install a CLI built with TS. My agent can figure out how to install this.
It's not just the complexity. You're also vulnerable to supply chain attacks via NPM. It's also performance as you don't need the entire javascript runtime just for a CLI.
You can get a binary compiled by the author or a trusted source and none of the dependencies can change out from under you. This isn't possible with an interpreted language where the dependencies are resolved (often from dubious places like npm) at install and update time.
You can write a CLI in typescript and bundle it into a a single JS file. In fact (without looking) I’m sure that’s what Cloudflare is doing here because it’s standard practice.
Javascript is plenty fast, but only if it has enough time to JIT the code and can keep it JITed in memory. For long-running backed services, it's plenty fast, for browser things, it's the only option, but for the command line, it adds needless startup time.
Agents make this even worse because they don't have a "sense of time", so if they accidentally do something which causes startup time to increase dramatically, they won't feel it like a human dev would, and won't immediately start optimizing. Unless you have some specific benchmarks in CI that fail any PR which makes the code too slow, agents will just make things slower and slower.
Counterpoint: many cloud CLIs are thinnish wrappers around APIs, so looking under the covers can actually be useful in figuring out how to do something in the API when documentation is unclear.
> I don't understand why this is written in Typescript
I suppose you're not very familiar with typescript then.
Listen, all this CLI app does is serve as an interface to send requests to the Cloudflare API. This means it only does things like sending HTTP requests, and outputting JSON. The cli app also needs to run on multiple platforms. Performance is not an issue or a concern.
I'd frame this the opposite way: what better tool do you think there is for this purpose other than TypeScript?
On top of that, there's the fact that Cloudflare's core services run on V8. If there is anything this company has, it's people familiar with JavaScript and TypeScript.
> Well, anything less susceptible to supply-chain attacks, obviously
Supply chain attacks are a factor only as far as a programming language supports modularization and has a large ecosystem. I mean, wasn't rust in the news recently due to cargo being used to execute supply chain attacks?
Different use case but Claude Code CLI and GitHub Copilot CLI, both JS monstrosities, use 500MB at idle per session and it's not uncommon to have 10+ sessions across multiple IDE's. 5GB RAM gone on just an LLM harness doing nothing.
At least Codex CLI in rust uses 80-100MB which is still not great but a big improvement.
These AI companies screw you over from both sides. They make the cost of RAM skyrocket and then they build terrible software that uses all the RAM you have.
There is no more code, there are only specs, apparently. So I guess it's a typescript spec so your agent can generate its own CLI, in optimized native assembly of your local CPU and customized to your needs ? ;)
1. There's always a possibility they evaluated Rust / Go, concluded the agentic code in those languages is less maintainable / productive (for AI agents) than typescript, but didn't spell it out to avoid internet flame wars. For instance, recent Microsoft rewrite of copilot almost doubled the code size.
2. They may intend the parts of it to be reused on workers?
> 1. There's always a possibility they evaluated Rust / Go, concluded the agentic code in those languages is less maintainable / productive (for AI agents) than typescript, but didn't spell it out to avoid internet flame wars.
This is a testament of how toxic the fanboys behind some of these language bandwagons became: people avoid mentioning their precious little tool wasn't the top choice to develop a project, because a mundane technical decision can gather so much vitriol from these types that a flame war is bound to happen.
`npm...` and then instant tab close. The total lack of self-awareness regarding how much they're asking us to infect our toolchain is hilarious. I mean, consider that agents can and should be containerized.... Like, that's what competent engineers- the target audience- are doing. It's just so completely tone-deaf.
Language choice is more often due to politics than practicality. Microsoft probably has some internal process for deciding on languages and "defaults" to typescript & C# since they have the most direct control over those languages.
"Claude, rewrite this in amd64 and arm64 assembly. Optimize it to the max, and make no mistakes. Oh yeah, formally verify it while there, may as well."
You laugh now but in 5 years when these LLM’s operate at thousands or tens of thousands of tokens per second on dedicated hardware in your phone… “might as well” won’t even be a joke.
I think these are both examples that help prove my point. Neither of these tools benefit the user by being in Python and distributing a runtime just for a CLI tool.
There’s no mention of how long the CLI takes to start. gcloud is hilariously slow even on human timescales, and even when not running it as a snap (sigh).
It can do everything except make the token to give it permissions. For that you need to dig through their website to find the tokens section. Oh and they change where that lives every week.
And the Cloudflare dashboard is soooo slooooow and logging in takes an eternity, using Passkeys often just doesn't work ("not tied to a specific account"???) and the loging in button takes forever to be clickable because of some bot checks running in the background.
This is cool, but I've never had an issue with agents working on Cloudflare by just making REST calls. With the rest docs, it knows pretty much everything about what kind of operations it can do. Is the CLI a subset of that or does in encompass everything?
Yes I am doing that too. I have a separate folder called ai/cloudflare. the AGENTS.md references the cf docs and instructs the agent to leave a change log + write down learnings whenever it does something
It’s now so good that I cd into this folder and say things like “add this and that to this configuration” and the agent immediately knows how to do it
I’m guessing cf just wraps the API into a CLI that’s easier to traverse and explore
Cloudflare keeps denying my (human) browsing because of "incompatible browser extensions", and sites require javascript and cookies because of all their nonsense.
Please do not put cloudflare between your site and humans, they are not a trusted gatekeeper.
This is a lot to like here as someone who pretty much exclusively uses the Cloudflare API via agents. Hoping (since it's built on top of Forge), some kind of native terraform support is also in the works.
Great when you're a solo dev deploying a worker, but would be incredible for production deployments if this could also just natively output terraform code.
I think the shape of clouds and services is going to change given current clouds are uxed for humans. Cloudflare is making the right bet. Specially the free agent report account. That's like a wonderful idea for building agent share.
Is this a joke? Why would you want to use a random word generator on production infrastructure configuration? Cloudflare should be blocking these malicious/incompetent users, not enabling them.
Kudos to cloudflare on this, it looks like a great CLI, I especially like the `cf cli search`.
Related, Matt Pocock's skill for having agents generate an interactive bash script for things only humans can do (or should do), presented in the context of devops like activities
I have found that having the agents write scripts to use tools like this is better (less tokens, more reliability, fewer side quests) than giving it to them directly with markdown they may or may not follow on any given day.
The other benefit to this is that you can put scripts on either side of the agent and remove all credentials from their process, removing whole classes of issues you don't want to have to tell your boss about. CLIs like this are great for read-only debug sessions, but if you are going to make modifications to your cloud infra, keep doing IaC.
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.
I was pointing out a minor consideration for Rust on server vs TS on local in general, not current `cf` specifically.
> Is this sarcasm? We’re talking about a CLI.
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.
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.
> Choice of tech stack is not merely a question of performance, but also portability and packaging.
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.
> wrangler
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.
> 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:
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
> I just tested gcloud (...)
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.
When you have buggy software like Claude Code where they literally had to buy the company that made the software and then machine translate it to Rust just to make it fast enough, it's not "a complete waste of time." Somehow people can turn even CLIs into unoptimized garbage.
I don’t agree with that at all, there is a high startup cost to languages like Java and to a lesser extent, JS. Java won’t do anything at all for about 60ms last I measured. This is noticeable to users. JS does better which is why you still see some JS based CLIs. But languages like Go and Rust really are much better for this, they don’t require a huge VM installed on your system and start up instantly. I can also recommend Common Lisp as it has an insanely low startup latency. Ship a single file binary without dependencies please.
I mean it is the reason they would like to give. Should we accept it though as their core motivation vis-a-vis it is most convenient and low effort for them so they will do it.
this has to be satire - it may be the most retarded thing I have ever read
This is also not correct in this case since they recently rewrote the Artifacts backend from Zig to TypeScript.
My read is that it's generally the teams that have been assigned to build a certain product that end up choosing the architecture that it runs on. So when we see TypeScript involved in TUI and CLI applications, most of it is just a repurposing of skill sets from that domain into the terminal. In an organization like Cloudflare, I expect that the developers who don't specialize in TypeScript are working on far more important problems.
Are you really suggesting that the choice to use Typescript wasn't a deliberate one?
IMO -- it makes total sense within the existing Cloudflare tooling ecosystem.
Whether it was deliberate or not, I do not think it's a good choice. When agents can write in any language, there's no reason to pick the wrong tool for the job. At this point Javascript/Typescript belongs only in the browser. It's the suboptimal choice for every other environment. Especially for a command line tool. Even if the back-end is written in Typescript (also not the best choice imho), the clients need not be in the same language.
Various agent tools (including current versions of codex-rs, which is otherwise a normal Rust program) make effective use of JavaScript/TypeScript for “code mode”. I actually think it’s an excellent choice for this use case. (I think that a less weird language with otherwise similar optimizers and tooling would be even better, but JS/TypeScript is what we have.)
What would even be a good alternative? The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.
> The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.
JS as a tech stack breaks your "fully safe" constraint (unless you are talking about running a CLI JS application without using npm...)
In this particular instance, I mean JS-the-language, not JS-the-ecosystem with browser and/or npm-style APIs.
codex-rs's code-mode-runtime uses plain V8 and gives it limited capabilities. (It gives it a very strange set of capabilities, but the point is that a program can grant specified capabilities to a JS script that it hosts, and the JS script can use those capabilities and nothing else.)
I suppose I should have added Lisp-like langauges to my list, although those don't have the kind of static type checking that TypeScript can offer.
Typescript and the npm/JS ecosystem may be complex, but you don’t need AGI to figure out how to install a CLI built with TS. My agent can figure out how to install this.
It's not just the complexity. You're also vulnerable to supply chain attacks via NPM. It's also performance as you don't need the entire javascript runtime just for a CLI.
Pretty much every modern language with a package repository is vulnerable to supply chain attacks.
Are there any languages doing something unique or are especially resilient in this respect?
You can get a binary compiled by the author or a trusted source and none of the dependencies can change out from under you. This isn't possible with an interpreted language where the dependencies are resolved (often from dubious places like npm) at install and update time.
You can write a CLI in typescript and bundle it into a a single JS file. In fact (without looking) I’m sure that’s what Cloudflare is doing here because it’s standard practice.
> It's not just the complexity. You're also vulnerable to supply chain attacks via NPM.
Oh you mean like the attacks that occur in Rust's cargo?
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
Installation is not the problem.
Javascript is plenty fast, but only if it has enough time to JIT the code and can keep it JITed in memory. For long-running backed services, it's plenty fast, for browser things, it's the only option, but for the command line, it adds needless startup time.
Agents make this even worse because they don't have a "sense of time", so if they accidentally do something which causes startup time to increase dramatically, they won't feel it like a human dev would, and won't immediately start optimizing. Unless you have some specific benchmarks in CI that fail any PR which makes the code too slow, agents will just make things slower and slower.
Code should be written for the user.
> Code should be written for the user.
Yes, and the user wants to use a command line app, regardless of what's running underneath.
Counterpoint: many cloud CLIs are thinnish wrappers around APIs, so looking under the covers can actually be useful in figuring out how to do something in the API when documentation is unclear.
Seriously there’s zero benefit to be writing CLIs in typescript in 2026
> I don't understand why this is written in Typescript
I suppose you're not very familiar with typescript then.
Listen, all this CLI app does is serve as an interface to send requests to the Cloudflare API. This means it only does things like sending HTTP requests, and outputting JSON. The cli app also needs to run on multiple platforms. Performance is not an issue or a concern.
I'd frame this the opposite way: what better tool do you think there is for this purpose other than TypeScript?
On top of that, there's the fact that Cloudflare's core services run on V8. If there is anything this company has, it's people familiar with JavaScript and TypeScript.
> I'd frame this the opposite way: what better tool do you think there is for this purpose other than TypeScript?
Well, anything less susceptible to supply-chain attacks, obviously.
> Well, anything less susceptible to supply-chain attacks, obviously
Supply chain attacks are a factor only as far as a programming language supports modularization and has a large ecosystem. I mean, wasn't rust in the news recently due to cargo being used to execute supply chain attacks?
Different use case but Claude Code CLI and GitHub Copilot CLI, both JS monstrosities, use 500MB at idle per session and it's not uncommon to have 10+ sessions across multiple IDE's. 5GB RAM gone on just an LLM harness doing nothing.
At least Codex CLI in rust uses 80-100MB which is still not great but a big improvement.
These AI companies screw you over from both sides. They make the cost of RAM skyrocket and then they build terrible software that uses all the RAM you have.
There is no more code, there are only specs, apparently. So I guess it's a typescript spec so your agent can generate its own CLI, in optimized native assembly of your local CPU and customized to your needs ? ;)
1. There's always a possibility they evaluated Rust / Go, concluded the agentic code in those languages is less maintainable / productive (for AI agents) than typescript, but didn't spell it out to avoid internet flame wars. For instance, recent Microsoft rewrite of copilot almost doubled the code size.
2. They may intend the parts of it to be reused on workers?
They literally write large parts of their codebase already in Rust and with agents, and Rust workers are supported so I really don't know the cause.
Didn't know there was rust worker support. I stand corrected.
> 1. There's always a possibility they evaluated Rust / Go, concluded the agentic code in those languages is less maintainable / productive (for AI agents) than typescript, but didn't spell it out to avoid internet flame wars.
This is a testament of how toxic the fanboys behind some of these language bandwagons became: people avoid mentioning their precious little tool wasn't the top choice to develop a project, because a mundane technical decision can gather so much vitriol from these types that a flame war is bound to happen.
`npm...` and then instant tab close. The total lack of self-awareness regarding how much they're asking us to infect our toolchain is hilarious. I mean, consider that agents can and should be containerized.... Like, that's what competent engineers- the target audience- are doing. It's just so completely tone-deaf.
I couldn't figure out why Microsoft wrote Github copilot CLI in typescript either.
Language choice is more often due to politics than practicality. Microsoft probably has some internal process for deciding on languages and "defaults" to typescript & C# since they have the most direct control over those languages.
"Claude, rewrite this in amd64 and arm64 assembly. Optimize it to the max, and make no mistakes. Oh yeah, formally verify it while there, may as well."
You laugh now but in 5 years when these LLM’s operate at thousands or tens of thousands of tokens per second on dedicated hardware in your phone… “might as well” won’t even be a joke.
Oh, I'm not entirely sure I was joking. This is already well possible at this point, it's just goofy sounding.
That still feels like chartering a helicopter for a 20-minute drive just because helicopters got cheaper and faster.
Typescript is perfect for that kind of application. Plus, the same code runs everywhere, no need to ship native binaries for every OS and CPU.
Optimization for me but not for thee.
AWS and GCP CLIs have been in Python for a decade or more. Last I checked Python was not a compiled language
Raise your hand if you have been personally traumatized by the miniature standalone py3 distribution bundled within the aws cli.
Yeah, and they're terrible. If anything they're a prime example of what 100% should be written in a compiled language.
I think these are both examples that help prove my point. Neither of these tools benefit the user by being in Python and distributing a runtime just for a CLI tool.
There’s no mention of how long the CLI takes to start. gcloud is hilariously slow even on human timescales, and even when not running it as a snap (sigh).
IMO these tools should strive to start quickly.
the point is probably to have a ts library as well for consumers, so it kind of makes sense.
i'd probably write it in rust and expose ts bindings tho.
Wow, the first four comments are negative. Welcome to Hacker News everybody!
It's crazy that some of the best product launches nowadays are CLIs.
Agreed. Cloudlflare appear to be innovating really well.
It can do everything except make the token to give it permissions. For that you need to dig through their website to find the tokens section. Oh and they change where that lives every week.
And the Cloudflare dashboard is soooo slooooow and logging in takes an eternity, using Passkeys often just doesn't work ("not tied to a specific account"???) and the loging in button takes forever to be clickable because of some bot checks running in the background.
As bad as the AWS console UX is, at least it’s mostly additive/unchanging over time.
I frequently hit strange UI bugs with Cloudflare workers, where I need to do a hard refresh to make things right.
This is cool, but I've never had an issue with agents working on Cloudflare by just making REST calls. With the rest docs, it knows pretty much everything about what kind of operations it can do. Is the CLI a subset of that or does in encompass everything?
The actual title is
> Introducing cf: the agentic CLI for the entire Cloudflare API
emphasis my own to highlight the key word missing in the HN title
Yes I am doing that too. I have a separate folder called ai/cloudflare. the AGENTS.md references the cf docs and instructs the agent to leave a change log + write down learnings whenever it does something
It’s now so good that I cd into this folder and say things like “add this and that to this configuration” and the agent immediately knows how to do it
I’m guessing cf just wraps the API into a CLI that’s easier to traverse and explore
[dead]
Cloudflare keeps denying my (human) browsing because of "incompatible browser extensions", and sites require javascript and cookies because of all their nonsense.
Please do not put cloudflare between your site and humans, they are not a trusted gatekeeper.
1.0 isn't actually out and CI is red. https://github.com/cloudflare/cf/commits/main/ https://github.com/cloudflare/cf/releases
I have been using the pre-releases with success, but this post could have waited a few days!
I don't know what it is about wrangler that made me dislike it so much but I welcome this change since it's meant to replace wrangler.
It feels heavy, the emojis are overused, and it is probably the only CLI tool I've felt as "clunky". Maybe that and Claude Code TUI.
re: wrangler, my biggest gripe was inconsistency between dev and prod
I think I may be confusing my annoyance with pages vs workers and agents that kept deploying to pages due to outdated training data.
Wrangler still didn't feel great to use.
This is a lot to like here as someone who pretty much exclusively uses the Cloudflare API via agents. Hoping (since it's built on top of Forge), some kind of native terraform support is also in the works.
Great when you're a solo dev deploying a worker, but would be incredible for production deployments if this could also just natively output terraform code.
[flagged]
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.
Of course, it's impossible to know for sure what was LLM processed or not, but your posts have been getting classified that way.
I think the shape of clouds and services is going to change given current clouds are uxed for humans. Cloudflare is making the right bet. Specially the free agent report account. That's like a wonderful idea for building agent share.
Nice! I would recommend you support one of the opencli specs, like https://clidoc.dev so that it is fully discoverable with examples, etc.
"Our new configuration format is based on TypeScript" This is the most head scratching but interesting bit.
Is this a joke? Why would you want to use a random word generator on production infrastructure configuration? Cloudflare should be blocking these malicious/incompetent users, not enabling them.
Scratching my head too. The thing is, the industry as whole is enabling this type of behavior
Great now i have to uninstall the Cloudfoundry CLI to not collide with this :)
helpful tip is to make use of single letter personal aliases. g=git c=cf or cf ;)
so uh, the favicon for cloudflare and soundcloud are just the same thing now? soundcloudflare?
[flagged]
[dead]
[dead]
[flagged]
[dead]
Kudos to cloudflare on this, it looks like a great CLI, I especially like the `cf cli search`.
Related, Matt Pocock's skill for having agents generate an interactive bash script for things only humans can do (or should do), presented in the context of devops like activities
https://github.com/mattpocock/skills/blob/main/skills/produc...
I have found that having the agents write scripts to use tools like this is better (less tokens, more reliability, fewer side quests) than giving it to them directly with markdown they may or may not follow on any given day.
The other benefit to this is that you can put scripts on either side of the agent and remove all credentials from their process, removing whole classes of issues you don't want to have to tell your boss about. CLIs like this are great for read-only debug sessions, but if you are going to make modifications to your cloud infra, keep doing IaC.
You linked to /skills/productivity/to-questionnaire/SKILL.md
Did you mean to link to /skills/engineering/wizard/SKILL.md ?
ah yea, that is the one!
thanks for surfacing this for everyone
link: https://github.com/mattpocock/skills/blob/main/skills/engine...