Our goal is to make the software pieces as efficient as possible and there were a few areas we wanted to improve:
Zero-dependency Install — currently Node v22+ is required, which is frustrating or a blocker for some users
Native Security Bindings — surprise! we already ship a Rust for linux sandboxing since the bindings were available
Optimized Performance — no runtime garbage collection, resulting in lower memory consumption
Extensible Protocol — we’ve been working on a “wire protocol” for Codex CLI to allow developers to extend the agent in different languages (including Type/JavaScript, Python, etc) and MCPs (already supported in Rust)
Now to be fair, these dashes scream “LLM generated” for their entire post. Regardless, if these really are their reasons:
Zero-dependency Install - there are a ton of languages where this is true. Self-contained installs are possible in Python, C#, Rust, C++, etc. Go is one option here too, but doesn’t really provide anything more than the rest of these languages.
Native Security Bindings - they supposedly already do this in Rust
Optimized Performance - this seems overblown on their part in my opinion, but no runtime GC seems to constrain us to C, C++, Rust, and some others like Zig. Go, C#, Python, etc all do runtime GC. Regardless, in my opinion, runtime GC doesn’t actually matter, and all of these options have enough performance (yes even Python) for what they need.
Extensible Protocol - this is doable in many languages. It seems to me here that they already have some work in Rust that they want to use.
As for the difficulty in making a CLI, clap makes CLIs dead simple to build with its derive macro. To be clear, other languages can be just as easy (Python has a ton of libraries for this for example including argparse and Typst).
Personally, if I were to choose a language for them, it’d be Python, not Go. It would have the most overlap with their users and could get a lot more contributors as a result in my opinion. Go, on the otherhand, may be a language their devs are less familiar with or don’t use as much as Rust or other languages.
I mean, it sounds like it’s gonna be a fairly large codebase. Rust is definitely better equipped for large codebases than Python…
I do agree that Python could give them more outside contributors, but from my experience, I don’t think it’s worth swaying from your preferred tooling for that. Outside contributions will make up barely a fraction of code changes either way, so you should rather ensure that your core team is productive.
Are you referring to the workspace feature of uv? Is that working well?
Management might want us to revive a project from a few years ago, which is like 5% Python, but for which we had to build a homegrown horrid implementation of workspace builds, using shell scripts and symlinks. We’d definitely want to get rid of that, if uv’s workspace builds work at all, really. 🫠
Quoting OpenAI:
Now to be fair, these dashes scream “LLM generated” for their entire post. Regardless, if these really are their reasons:
As for the difficulty in making a CLI, clap makes CLIs dead simple to build with its derive macro. To be clear, other languages can be just as easy (Python has a ton of libraries for this for example including argparse and Typst).
Personally, if I were to choose a language for them, it’d be Python, not Go. It would have the most overlap with their users and could get a lot more contributors as a result in my opinion. Go, on the otherhand, may be a language their devs are less familiar with or don’t use as much as Rust or other languages.
M-Dash and a bullet point list? Yeah, that’s AI generated.
I mean, it sounds like it’s gonna be a fairly large codebase. Rust is definitely better equipped for large codebases than Python…
I do agree that Python could give them more outside contributors, but from my experience, I don’t think it’s worth swaying from your preferred tooling for that. Outside contributions will make up barely a fraction of code changes either way, so you should rather ensure that your core team is productive.
Python can also be used for large codebases (thanks
uv), but I agree that Rust is better suited to the job.Are you referring to the workspace feature of
uv? Is that working well?Management might want us to revive a project from a few years ago, which is like 5% Python, but for which we had to build a
homegrownhorrid implementation of workspace builds, using shell scripts and symlinks. We’d definitely want to get rid of that, ifuv’s workspace builds work at all, really. 🫠uv’s workspaces work, yep. It’s honestly great. Haven’t really run into any issues with them yet.