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.

> 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.

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.

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.

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.

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.

For cli I'm sure the biggest drawback of node is the lack of portability and very large footprint of the "executables".

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.

CLIs are different than other software, as they're launched and killed often.

> And now everyone is rewriting everything in Go/Rust left and right.

Seems like confirmation bias.

If only we could shift off of React Native as well.

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.

If it was possible, then OpenAI will stop selling AI and start selling services.

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).

> 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.

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

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].

[1]: https://github.com/joshka/tui-markdown/pull/80

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.

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.

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.

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:

Looks open-source to me - https://github.com/openai/codex/tree/main/codex-rs

Making changes to huge rust projects is quite easy. For a substantial alteration, you make your change, the compiler tells you the 100 problems it caused, and you fix them all (~50% auto fix, 30% Claude/Codex, 20% manual), then the program probably does the thing.

Architecting the original 100kloc program well requires skill, but that effort is heavily front loaded.

What kind of performance gains can you get from that? Seems to me that 99.9% of the compute happens remotely.

I get why OpenAI didn't invest time and money into this, but I do wonder if there's some reason that nobody have written a JavaScript frontend for LLVM.

There shouldn't be a reason why you couldn't and it would give you performance and zero dependency install.

Thank you. It is not clear what "going native" means.

Getting Node installed is a blocker for some of their customers, evidently. It doesn't surprise me. If it holds back one mid sized enterprise customer, the rewrite is worth it.

node install can be a real pain sometimes. node ecosystem has had a number of security related issues over the years. supply chain attacks are one of my main fears.

Is that not a valid justification?

> LLMs provide 0 business value (any value is offset by uncertainty)

Hilarious take.

I think you've highlighted the real engineering challenge of using LLMs - overcoming the uncertainty. In some contexts, a reasonable level of uncertainty is fine, as the tool itself is being used by experts ( ie the coding tools), but in other cases, you need to engineer a lot more guardrails to ensure a result of sufficient quality.

> ? LLMs provide 0 business value

Usage is in the eye of the user, I see.