Codex CLI is going native
129 comments
·June 1, 2025wiseowise
cameronh90
It really comes down to the Go and Rust ecosystems being easy to work with. A decade or two ago, writing a native app meant setting up an automake/autoconf Rube Goldberg machine - especially difficult if you needed to build for multiple architectures.
I'd argue Rust and Go are even easier to work with than Python/JS/TS. The package management is better, and static linked native binaries eliminate so many deployment headaches.
pjmlp
As someone educated in the likes of BASIC and Z80, it isn't as if it was really that complicated, versus the willigness to learn.
Sometimes people really need to follow Yoda and Mr Miyagi advices, instead of jumping right into it.
cameronh90
It is complicated, though. Not as complicated as quantum physics, but still far more complicated than it needs to be - especially if you care about multiple architectures and platforms. At one point I was making builds for X86, AMD64 and Itanium on Windows, MacOS, Linux (which itself was subdivided into various distributions with different glibc/openssl/whatever versions). It took more work maintaining the build pipeline than working on features.
Go and Rust prove you can get most of the benefit of C/C++ without paying that complexity cost.
jvanderbot
Both can be true. It can be easy to learn and also a complete pain to set up and get right for every new project and menu of architectures you want to support.
fragmede
cross compiling to Mac from Linux, cross-architecture used to be an impossible bitbake adventure to go on. in go, it's just two env vars!
metaltyphoon
With a big footnote: Until you need CGO
diggan
> And now everyone is rewriting everything in Go/Rust left and right.
Especially interesting for software that are 99.9% of the time waiting for inference to come back to you. Sure, makes sense to rewrite something that is heavily relying on the CPU, or where you want an easier time to deal with concurrency, but I feel like that's not what makes Codex takes long time to finish a prompt.
With that said, I also rewrote my local LLM agent software to Rust, as it's easier to deal with concurrency compared to my initial Python prototype. That it compiles into a neat binary is an additional benefit, but could have as easily gone with Go instead of Rust.
gwynforthewyn
> Especially interesting for software that are 99.9% of the time waiting for inference to come back to you.
In a different domain, I’ve seen a cli tool that requests an oauth token in Python be rewritten to rust and have a huge performance boost. The rust version had requested a token and presented it back to the app in a few milliseconds, but it took Python about five seconds just to load the modules the oauth vendor recommends.
That’s a huge performance boost, never mind how much simpler it is to distribute a compiled binary.
rybosome
I’ve spent some time optimizing Python performance in a web app and CLI, and yeah it absolutely sucks.
Module import cost is enormous, and while you can do lots of cute tricks to defer it from startup time in a long-running app because Python is highly dynamic, for one-time CLI operations that don’t run a daemon or something there’s just nothing you can do.
I really enjoy Python as a language and an ecosystem, and feel it very much has its place…which is absolutely not anywhere that performance matters.
EDIT: and there’s a viable alternative. Python is the ML language.
emporas
Python's startup cost is terrible. Same with Node. Go is very good, but Rust is excellent.
Even if a GC'ed language like Go is very fast at allocating/deallocating memory, Rust has no need to allocate/deallocate some amount of memory in the first place. The programmer gives the compiler the tools to optimize memory management, and machines are better at optimizing memory than humans. (Some kinds of optimizations anyway.)
teaearlgraycold
Packaging Python apps is pure hell. npm gets a lot of shit, but Python deserves as much if not more.
dweekly
Everything follows a cycle. Client/server, flat/skeuomorphic, compiled/interpreted, cloud/colo, colorful/minimalist, microservices/monolithic, standards-driven/vendor-driven, open/proprietary, CPU/xPU. There is a natural tension in the technical universe that pushes progress in one direction that loads the spring in the other direction. Over time you'll see the cycles rhyme.
BrouteMinou
I can't wait for the "rewritten in Rust" era to end!
tonyhart7
wait until Zig(and ecosystem) got mature first
this is next Trends
apwell23
crazy how fast "rewritten in Go" ended . now suddenly all those native go projects are uncool again.
mbb70
Feels like the big shift is Rust hitting critical mass mindshare and LLM assisted translation making these rewrites viable. Rust is a very vibable language.
An announcement of Codex CLI being rewritten in C++ would be met with confusion and derision.
energy123
> Rust is a very vibable language.
Why would you say this for Rust in particular?
falcor84
Once a Rust program finally compiles it's much likelier that it's correct, in comparison to other languages, at least in the sense of avoiding unexpected runtime behavior.
csomar
If you properly structure your types and document them well, you can speed run lots of code generation.
wrsh07
Good error messages which are great for humans but also great for LLMs that are trying to debug their initial attempt
lmm
I suspect it's accidents of history that those are "native". Go's advantage is in its Google backing, and Rust is just a good language design that's managed to hit on the right kind of community. As far as I can see all the reasons that native was unnecessary are still valid.
amazingamazing
> And now everyone is rewriting everything in Go/Rust left and right.
Seems like confirmation bias.
pjmlp
And then they ship an Electron based GUI on top.
Note that most of these rewrites wouldn't be needed if the JIT language would be Java, C#, Common Lisp, Dart, Scheme, Raket.
And all of that list also have AOT compilers, and JIT cache tooling.
NitpickLawyer
> And then they ship an Electron based GUI on top.
If this catches on, and more tools get the "chatgpt, translate this into rust, make it go brrr" treatment, hopefully someone puts in the time & money to take tauri that extra 10-20% left to make it an universal electron replacement. Tauri is great, but still has some pain points here and there.
h1fra
For cli I'm sure the biggest drawback of node is the lack of portability and very large footprint of the "executables".
crop_rotation
Codex is terrible compared to claude code, even though the individual models of anthropic are not really that much better than openAI. They should have made that their top priority instead of a rewrite which will just make the improvements take a back seat.
serverlessmania
Had an awful experience with Claude Code—it couldn’t even handle a basic API test for existing code, while Codex with o3 nailed it in one shot.
Claude Code tends to write meaningless tests just to get them to pass—like checking if 1 + 1 = 2—and somehow considers that a job well done.
smohare
[dead]
adsharma
Wouldn't it be a great showcase if codex showed that the rewrite to rust was done using codex itself instead of a human?
If it's not possible today, what are the challenges and where does a human need to step in and correct the model?
csomar
If it was possible, then OpenAI will stop selling AI and start selling services.
tptacek
This has been coming for awhile now (there's been a Rust fork available to try forever); as I understand it, the impetus here is just getting the CLI installed places where Node is annoying to install.
pjmlp
With all the RIIR going on nodejs ecosystem, I am waiting for the blog posts on how people completely got rid of nodejs, rewriting the whole backend in Rust and how everything is so much better.
Waiting for Show HN: AbrasionNext, the framework evolution for frontend devs, with SaaS cloud deployment.
wiseowise
It seems Rust "just" needs RoR level web framework and Qt level GUI framework to take over the world, everything else is already conquered (with some Go conclaves still holding on).
ogoffart
> Qt level GUI framework
Trying to bring that with Slint: https://slint.rs
csomar
> RoR level web framework
This is not happening. The new folks have moved to SPA/RSC and a RoR type framework doesn't make much sense in that context.
spiderice
Elixir/Phoenix is doing great
tonyhart7
"It seems Rust "just" needs RoR level web framework"
its already HERE https://loco.rs/
I writing a production level app right now with it
satvikpendem
> I am waiting for the blog posts on how people completely got rid of nodejs, rewriting the whole backend in Rust
I did this for several projects, works great with much lower costs and compute/memory usage.
gavinray
This is one of the most ridiculous RIIR I've seen.
It's a CLI tool that makes API calls. I'd bet my bottom dollar that the performance difference between API-wrapping CLI tools in something like Ruby/Python vs Rust/C++ is negligible in perceived experience.
If they wanted people to not have a dependency on Node pre-installed, they could have shipped Single Executable Application's [0] or used a similar tool for producing binaries.
Or used Deno/Bun's native binary packaging.
[0] - https://nodejs.org/api/single-executable-applications.html
franga2000
Having the CLI self-contained and easy to cross-compile is a huge improvement, as is the binary size (from what I've seen, wrapped Node binaries are huge). Also, a CLI tool should have low latency and no matter how good your engine is, an interpreter will have much higher startup latency than a proper binary.
null
geertj
I wonder how much of the rewrite was done using codex itself. It does seem like a perfect use case for it.
joshka
I imagine a reasonable amount. The maintainer who is doing most of the Rust rewrite submitted a PR to one of the Ratatui widget libraries I maintain that seemed to be Codex produced[1].
tymscar
This is an interesting proof of what I keep reading about. Where people are quick at making something, like a PR, with AI, but then doing the last 10% is left in the air.
If codex was half as good as they say it is in the presentation video, surely they could’ve sent a request to the one in chatgpt from their phone while waiting for the bus, and it would’ve addressed your comments…
winrid
The last 10% you're referring to are nits. That's like the last 0.000001%. also, it could have fixed all these in like a minute by itself.
apwell23
Thats an interesting question. how much of code at these companies is written by tools they are selling.
I suspect its not much because I never see any stats published by any of these companies.
NitpickLawyer
Aider does publish this, and it's fascinating - https://aider.chat/HISTORY.html
> Aider writes most of its own code, usually about 70-80% of the new code in each release. These statistics are based on the git commit history of the aider repo.
apwell23
> Whenever aider edits a file, it commits those changes with a descriptive commit message.
interesting model. every prompt response acceptance gets a git commit without human modifications .
quotemstr
It's interesting how people conflate language choice with memory management strategy, compilation mechanism, distribution toolset, and type system strictness. I mean, on one hand, people explain that Rust's manual memory management makes it fast, but then also praise garbage collected Go for its speed and low startup latency. It's not that manual=fast and GC=slow: it's that Go's GC doesn't suck, and you can make fast GCed programs and slow manually memory managed ones (like games and their infamous loading screens). The equation of GC with slow is just a simplifying idea embedded in industry consciousness.
Likewise, you can make a single file distribution of a TypeScript program just fine. (Bun has built in support even.) But people don't think of it as a "thing" in that ecosystem. It's just not the culture. TypeScript means npm or Electron. That's the equivalence embedded in the industry hive mind.
To be clear, I'm not decrying this equivalence. Simplification is good. We use language as a shorthand for a bundle of choices not necessarily tied to language itself. You can compile Python with Nuitka or even interpret C. But why would you spend time choosing a point on every dimension of technical variation independently when you could just pick a known good "preset" called a language?
The most important and most overlooked part of this language choice bundle is developer culture. Sure, in principle, language choice should be orthogonal to mindset, areas of interest, and kinds of aptitude. But let's be real. It isn't. All communities of humans being and Go developers evolve shared practices, rituals, shibboleths, and priesthoods. Developer communities are no exception.
When you choose, say, Rust, you're not just choosing a language. You're choosing that collection of beliefs and practices common among people who like to use that language. Rust people, for example, care very much about, say, performance and security. TypeScript people might care more about development speed. Your C people are going to care more about ABI stability than either.
Even controlling for talent level, you get different emphases. The Codex people are making a wire format for customizing the agent. C people would probably approach the problem by making a plugin system. TypeScript people would say to just talk to them and they'll ship what you need faster than you can write your extension.
Sometimes you even see multiple clusters of practitioners. Game development and HFT might use the same C++ syntax, but I'd argue they're a world apart and less similar to each other than, say, Java and C# developers are.
That's why language debates get so heated: they're not just expressing a preference. They're going to war for their tribe. Also, nothing pisses a language community off more than someone from a different community appropriating their sacred syntax and defiling it by using it wrong.
Codex isn't so much swapping out syntax as making a bet that Rust cultural practices outcompete TypeScript ones in this niche. I'm excited to see the outcome of this natural experiment.
rgbrgb
I enjoy this ethnographic take on programming language choice being as much about culture as technical features. I wonder what effect LLM coding agents will have here as it makes big rewrites between languages trivial and potentially allows developers to quickly shift their programs between languages to gain advantages. Echoes some of the immigration debates the right stirs up.
pjmlp
Many are yet to fully grasp their favourite languages will become irrelevant, when agents start spewing executables directly.
We are in the middle of a transition in programming paradigms.
Let the AI coding models flamewars start.
pjmlp
Somehow compilers should be part of any kind of computing related teaching, as means to dispel programming languages urban myths.
Unfortunately that in an utopia that will never realise.
People will keep learning programming languages based on hearsay, whatever books they find somewhere, influencers and what not.
quotemstr
If I were drafting a CS curriculum, I'd include as mandatory projects writing both a C interpreter and a Scheme compiler.
ThouYS
sounds like a post-hoc rationalization for the whims of their devs. that being said Node was a weird choice to begin with
null
vendiddy
I would love for them to optimize the ChatGPT desktop client. It lags on me quite frequently.
jbellis
I'm surprised that performance wasn't on the list. The main reason I started Brokk on the JVM was for access to https://github.com/joernio/joern, but high performance code that can easily go multicore is a very nice secondary reason.
jauntywundrkind
On the list:
> Optimized Performance — no runtime garbage collection, resulting in lower memory consumption
Introducing the list (efficiency resonates with me as a more specific form of performance):
> Our goal is to make the software pieces as efficient as possible and there were a few areas we wanted to improve:
jbellis
gc is negligible impact on llm agents
the others ("zero dependencies") are not actually related to efficiency
jauntywundrkind
It's not totally unjustified to hone in on GC as over focusing. But it feels strongly overfocusing to me.
Efficiency is the top level goal, and that equates directly to performance in most computing tasks: more efficiency means being able to let other work happen. There's times where single threaded outright speed is better, but usually in computing we try as hard as possible to get parallelism or concurrency in our approaches such that efficiency can directly translate to overall performance.
Overall performance as a bullet seems clear enough. Yes it's occluded by a mention of GC, but I don't think the team is stupid enough to think GC is the only performance factor win they might get here, even if they don't list other factors.
Even a pretty modest bit of generosity makes me think they're doing what was asked for here. Performance very explicitly is present, and to me, I think quite clearly a clear objective.
simianwords
gc is especially not relevant in async flows. i don't know what they are optimising for..
justachillguy
Would love to see OpenAI add Codex CLI as part of their subscription and not API pricing.
Recent resurgence of tools going native is really interesting. For years (at least last decade) I've heard mantra that JIT/interpreters are getting so good that you don't need to bother with native languages anymore, clients can be written in Python/Ruby, because it's a one-off operation anyway, etc., etc.
And now everyone is rewriting everything in Go/Rust left and right.