Hello! Thank you all for the excitement, feedback, and contributions over the past month or so since launch. It's been incredible to hear from all of you building with Codex CLI and now Codex in Ch...
Read the original article
Comments
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.
By cameronh90 2025-06-0122:162 reply 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.
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!
By metaltyphoon 2025-06-024:022 reply With a big footnote: Until you need CGO
By supriyo-biswas 2025-06-024:492 reply Having recently done some investigation along the same lines for a side project that I did not continue to work on: is it not just a matter of passing CGO_LDFLAGS=—static and building on musl?
By metaltyphoon 2025-06-0212:45 or FreeBSD
By steveklabnik 2025-06-0216:32 To say what your siblings said, but more generally: basically this only works for Linux. Other OSes generally don't let you do this, you must have some degree of dynamic linking.
Go used to try and let you do it, but has walked back those implementations after all the bugs they've caused, in my understanding.
By fragmede 2025-06-024:04 fair.
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.
By cameronh90 2025-06-0213:421 reply 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.
By pjmlp 2025-06-0216:06 Well, Modula-2 and Object Pascal already proved that quite a time ago, but they didn't come with curly brackets, nor UNIX.
By jvanderbot 2025-06-0212:19 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.
> 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.
By gwynforthewyn 2025-06-0114:043 reply > 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.
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.)
By nasretdinov 2025-06-0210:06 TBH I'm still surprised how quickly Go programs start up given how much stuff is there in init() functions even in the standard library (e.g. unicode tables, etc)
By rybosome 2025-06-024:10 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.
By teaearlgraycold 2025-06-0114:092 reply Packaging Python apps is pure hell. npm gets a lot of shit, but Python deserves as much if not more.
I know far too much about python packaging while only knowing a little about it.
I agree it’s hell. But I’ve not found many comprehensive packaging solutions that aren’t gnarly in some way.
IMHO the Python Packaging community have done an excellent job of producing tools to make packaging easy for folks, especially if you’re using GitHub actions. Check out: https://github.com/pypa/cibuildwheel
Pypa have an extensive list of GitHub actions for various use cases.
I think most of us end up in the “pure hell” because we read the docs on how to build a package instead of using the tools the experts created to hide the chaos. A bit like building a deb by hand is a lot harder than using the tools which do it for you.
By teaearlgraycold 2025-06-0118:071 reply That’s fair. I’m also thinking about the sheer size of Python apps that make use of the GPU. I have to imagine a C++ app performing neural network shenanigans would’t be >1GB before downloading weights.
By QuadmasterXLII 2025-06-021:271 reply I’ve tried, it is still gigabytes, unless you try to dynamically link to user installed CUDA libraries from c++. Which I don’t recommend.
By teaearlgraycold 2025-06-0215:21 Oof
By crabmusket 2025-06-0121:471 reply Speaking of which, I didn't realise Node had a built in packaging feature to turn scripts into a single executable:
By bxdhxhxh 2025-06-025:21 I was not aware of that feature either, thanks for the heads up
In my opinion, bundling the application Payload would be sufficient for interpreted languages like python and JavaScript
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.
By BrouteMinou 2025-06-0114:312 reply I can't wait for the "rewritten in Rust" era to end!
crazy how fast "rewritten in Go" ended . now suddenly all those native go projects are uncool again.
By jeremyloy_wt 2025-06-021:191 reply The official Typescript compiler is being rewritten in Go as we speak.
By apwell23 2025-06-022:12 ah intersting
"The existing code base makes certain assumptions -- specifically, it assumes that there is automatic garbage collection -- and that pretty much limited our choices."
By tonyhart7 2025-06-0114:38 wait until Zig(and ecosystem) got mature first
this is next Trends
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.
> Rust is a very vibable language.
Why would you say this for Rust in particular?
By falcor84 2025-06-0114:18 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.
By csomar 2025-06-023:45 If you properly structure your types and document them well, you can speed run lots of code generation.
Good error messages which are great for humans but also great for LLMs that are trying to debug their initial attempt
What about this which says the opposite:
By koakuma-chan 2025-06-0116:09 The comment you replied to is talking about Rust compiler's errors.
The comment you linked is talking about unspecified application's runtime errors.
By ralusek 2025-06-0114:08 Speaking for myself: one reason would be because it's one of the things LLMs/tools like Codex are the most useful for.
When I have a smallish application, with tests, written in one language, letting an LLM convert those files into another language is the single task I'm most comfortable handing over almost entirely. Especially when I review the tests and all tests in the new language are passing.
By lmm 2025-06-023:18 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.
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.
By NitpickLawyer 2025-06-024:32 > 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.
By h1fra 2025-06-0122:30 For cli I'm sure the biggest drawback of node is the lack of portability and very large footprint of the "executables".
By gofreddygo 2025-06-075:58 I'm interested in the business angle on this decision. How do you convince your boss hierarchy to throw hundreds of (wo)man hours on rewriting python/typescript/whatever in rust/go ?
What could it be that drives the ROI ?
You really notice the startup delay with a large CLI written in something like NodeJS. Going from >100ms to ~0ms is a huge QoL improvement.
By rane 2025-06-027:48 It largely depends on how often you have to run the command.
By miki123211 2025-06-0121:59 CLIs are different than other software, as they're launched and killed often.
By CSMastermind 2025-06-0122:56 If only we could shift off of React Native as well.
By amazingamazing 2025-06-0223:36 > And now everyone is rewriting everything in Go/Rust left and right.
Seems like confirmation bias.
By crop_rotation 2025-06-0114:141 reply 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.
By serverlessmania 2025-06-029:141 reply 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.
By smohare 2025-06-0216:27 [dead]
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?
