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)

[–] TehPers@beehaw.org 2 points 1 week ago (5 children)

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.

[–] Ephera@lemmy.ml 1 points 1 week ago (1 children)

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.

[–] TehPers@beehaw.org 2 points 1 week ago (1 children)

Python can also be used for large codebases (thanks uv), but I agree that Rust is better suited to the job.

[–] Ephera@lemmy.ml 1 points 1 week ago (1 children)

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

[–] TehPers@beehaw.org 1 points 1 week ago

uv's workspaces work, yep. It's honestly great. Haven't really run into any issues with them yet.

load more comments (3 replies)

load more comments (13 replies)