On the one hand, I love Rust, love seeing Rust winning, on the other hand: the cynical part of me observes this as a way for them to say it’s safer to use, somehow. In the sense that people fling Rust around in a kind of showey way.
Already we’ve been seeing projects fuck up with isolation irt MCP servers, so this is the backdrop to observe this kind of change.
I know this is blasphemy, but why not Go? Why Rust? I love writing Rust CLIs, but somehow I feel the personal arguments I make for such things don’t really hold up in industrial settings like this (in particular, a small open-source CLI project that interacts with networking).
There’s nothing wrong with using Rust here (Rust is great for business logic!), but the choice here almost makes me suspicious of the motivations.
Also there’s existing Rust solutions in this area! Namely: https://github.com/sigoden/aichat
I don’t really enjoy using AI when coding, but aspirationally, I’d rather support other projects than OpenAI, who is only a nonprofit in concept and is actively attempting to become a for-profit, whilst behaving like a VC funded startup.
(Not to mention the fact that mainline models are explicitly developed with the intention of destroying labor, in general)
I’ll be optimistic and say that someone at OpenAI loves working with Rust as much as you do and pushed for it 😄
I think I read somewhere that part of the motivation is that they won’t need a runtime to be installed to use it, but Go could fill that role as well of course.
But I think you said it yourself:
I know this is blasphemy, but why not Go? Why Rust? I love writing Rust CLIs
I guess they also prefer Rust to Go. I’d choose Rust over go for a CLI any day. Why do you say Rust wouldn’t be good in an “industrial setting”? I use Rust professionally and I don’t see any problems in that setting.
Go is a simpler-to-read language that does not involve lifetimes (as you know, it is GC’d). For a lot of smaller projects like this, the boringness of Go is preferred. Less mental bandwidth required.
I’ll admit my definition of “industrial” here was vague, but I think you can get my point. I’m not trying to say that Rust isn’t good in a business setting - my job also has Rust in the code!
However, for these purposes, most of the benefits of Rust in this situation are already provided by Go.
I don’t agree go is simpler to read. It is simpler to learn the syntax but the syntax is only part of what makes a language. Having learnt both, and having spent more time actually writing go I still prefer writing rust and finding it far easier to work with then go. Go has too many hidden gotchas that you need to trip up on to learn and then remember forever or else trip up on them again.
I agree here. I always find it difficult to navigate a Go codebase, especially when public members just seem to magically exist as opposed to being explicitly imported.
@solardirus @SorteKanin Maybe Go is easier to read in a word-for-word sense, but when I read a program, I want to understand what it does and why it works the way it works. I want to validate its properties to build a mental model of how pieces interact.
As soon as I start doing that I find Rust is much easier to reason about, because the compiler enforces a lot of properties that I rely on, whereas with Go I end up looking through multiple files to get the same picture.
@solardirus I find the situation to be the opposite, you need more mental bandwidth to navigate a go codebase. The signal to noise ratio is very poor because of badly designed error handling, poor libraries at some domains and lack of some modern goodies on programming languages making you having to reinvent the wheel every time.
Also, you rarely have to explicitly specify lifetimes.
Quoting OpenAI:
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.
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.
this as a way for them to say it’s safer to use, somehow.
And it probably is, because they use a lot of Ai for code generation too. And having Rust is a bit safer I assume, because its way stricter and the error message also way more helpful. Having not programmed in TypeScript, this is just an assumption and I just realized it gives you even right here. Oh the irony. :D
Yeah, TypeScript has to integrate with JavaScript for practicality’s sake, which pierces a hole in its ability to do proper, rigorous type checking. It’s closer to machine-readable documentation that helpfully flags some errors than an actual type-checked language, which will make you get your types right instead of gently suggesting that there might be an issue the way TypeScript does.
Pretty much. Rust is very strict and explicit about everything, while typescript lets you kinda jam things together in ways that are very convenient but harder to keep track of in your head.
Native is the New Normal?
That would be nice, if it works out as I’ve been wishing for.
