Yeah, they could probably get away with doing this in Go.

Probably minimal, it's mostly lower memory use from not having to boot a separate V8 engine with its own GC, like how Electron apps have to boot a separate browser engine. But CPU-wise it's not doing anything interesting on the client.

The neat thing for me is just not needing to setup a Node environment. You can copy the native binary and it should run as-is.

Probably uses less memory?

The big one is not having node as a dependency. Performance, extensibility, safety, yeah, don't really warrant a rewrite.

Don’t have to wait 2 seconds for the runtime to start.

If you're parsing JSON or other serialization formats, I expect that can be nontrivial. Yes, it's dominated by the llm call, but serializing is pure CPU.

Also, ideally your lightweight client logic can run on a small device/server with bounded memory usage. If OpenAI spins up a server for each codex query, the size of that server matters (at scale/cost) so shaving off mb of overhead is worthwhile.

> but I do wonder if there's some reason that nobody have written a JavaScript frontend for LLVM

Astral folks are taking notes. (I wouldn't be surprised if they already have a super secret branch where they rewrite Python and make it 100x faster, but without AI bullshit like Mojo).

What do you mean by “a JavaScript frontend for LLVM”?

Edit: ah, I see, I read “LLM” instead of LLVM at first! It's only after I posted my question that realized my mistake.

I'm not sure it makes sense to compile JavaScript natively, due to the very dynamic nature of the language, you'd end up with a very slow implementation (the JIT compilers make assumptions to optimize the code and fall back to the slow baseline when the assumptions are broken, but you can't do that with AoT).