[Feature] What if we rewrite orca by Rust

[orca-discord-issues[bot]]

Ed via Discord

🤔

[orca-discord-issues[bot]]

Jinjing via Discord

will leave this question to <@93764454222659584> ! he wrote Orca in the beginning 😄

[orca-discord-issues[bot]]

chevy787 via Discord

Oh so that's sorta the plan

[orca-discord-issues[bot]]

chevy787 via Discord

In short, I think the interface in which we work with AI is changing rapidly
And TS/electron in the language/framework which best matches the iteration speed.

With that being said, I totally want to double down once the model solidifies and model can port us to Rust in a single prompt.

Perry (TS -> Rust) is interesting, but I have another friend who's building 'Trust' and plans to have TS act as the spec in generation.
So in other words, give it a bit of time. Def working towards it. And perf for us is important (and there are several things we're doing now until we fully move into rust)

[orca-discord-issues[bot]]

gsxdsm via Discord

Core engine in Rust and UI in TS 🙂

[ioitiki]

tauri for desktop app

[orca-discord-issues[bot]]

gsxdsm via Discord

Maybe

[orca-discord-issues[bot]]

gsxdsm via Discord

I wonder how much speed rust would actually give

[orca-discord-issues[bot]]

Prethish via Discord

Tbh, We should only port when rust makes sense.
Right now, I would consider myself a heavy user and i have not found out any performance issues hindering my work.

[orca-discord-issues[bot]]

Prethish via Discord

End user does not care if it’s ts or rust as long as it does not bother them

[orca-discord-issues[bot]]

chevy787 via Discord

Yeah I think there's alot to still push just in TS

[orca-discord-issues[bot]]

chevy787 via Discord

Agreed, although with terminals rendering itself and interop ends up being a bit of a botteneck 🤔

But we might also get multi-threaded JS soon which would solve alot of things if AI can speed up the dev cycle on TC proposals

[orca-discord-issues[bot]]

vibing via Discord

Also agree with <@184302958266155008> I havent found perfomance to be an issue. Maybe useful to profile the app and find out the hotspots and whether it make to do it.

[orca-discord-issues[bot]]

gsxdsm via Discord

Same for me re performance

[WodenJay]

For me, I prefer low memory usage app cuzz I only have 16GB RAM. I think Rust is suitable to reduce RAM usage

[nwparker]

Move to dicussion! All valid.

We're making more perf changes and mem improvements. Though concrete rust work is prob a little bit further off

[iacore]

I want Orca to use less RAM. The UI is also sluggish somehow.

[nwparker]

We're making some major changes merging in Friday night (they're ready, just in testing -- you can try a -perf RC if you can't wait!).
Mainly around the way we handle terminals when you have many. Pretty big perf improvements.

[ioitiki]

i was previously using herdr. orca’s features and ux were enough to get me to switch, but the difference in smoothness is hard to ignore.

herdr feels like a thin layer over the terminal. orca sometimes feels like a full application hosting terminals, especially when several agents are running and producing lots of output.

i don’t think a full rust rewrite is necessarily the answer, but terminal rendering, PTY handling, and session orchestration seem like areas where a native core could have an outsized impact.

orca already wins for me on workflow and features. getting closer to herdr’s “you don’t feel the tool” responsiveness would make it incredibly hard to beat.

[jawad727]

I agree, if they built this in rust it'll make the product so much better.

[ioitiki]

Following up on my own comment above — I went through the codebase to pin down where a native core would actually move the needle, rather than just asserting "Rust = faster." Sharing in case it's useful when this gets prioritized. Fully agree with @nwparker that concrete Rust work is further off; think of this as the map for when we get there, not a push to start now.

TL;DR: the leverage is concentrated in a few byte-level hot paths, and Orca's own profiling docs + code comments already point straight at them. A native core (not a rewrite) targeting these looks like the high-ROI path, and the daemon boundary that already exists makes an incremental first step possible.

1. Terminal data plane — the biggest one

Every PTY byte currently gets:

• VT-parsed 3× by separate @xterm/headless / xterm instances (daemon, main process, renderer)
• JSON.stringify'd into NDJSON over the daemon↔main socket and JSON.parse'd back on the other side (control chars escape to 6 bytes, so worst-case wire size is ~6×)

docs/renderer-memory-profile-2026-06-01.md already measures ~460 MB RSS / ~40% CPU under a single active TUI, dominated by "V8, IPC, and deserialization" stacks. Because the daemon is already a separate forked process, it's the cleanest possible first Rust target: give it one authoritative VT state + native byte-capped scrollback + binary framing, and two of the three parses plus the JSON tax disappear — completely invisible to the renderer/xterm.

2. onPtyData per-chunk scanning

runtime/orca-runtime.ts runs a dozen JS text scans on every raw chunk ("hundreds/sec under load," per the comment there). The wait-blocked check is flagged in-code at ~85% of that path's cost before it was throttled. This is exactly the byte-crunching a native core absorbs, emitting only coalesced semantic events (status/title/cwd changed) up to JS.

3. Git

There's no git library today — each status poll is 3–9 git process spawns (worse on WSL, where every call is a wsl.exe → bash -c double-spawn with path translation). The main-thread-churn-probe built for #7576 measures this directly. In-process gitoxide/libgit2 for status + ahead/behind + numstat would delete most of it, along with the caching machinery built to work around the spawn cost.

4. Persistence

Durable state is a multi-MB pretty-printed JSON blob stringify'd (plus a second stringify for a sha1 dedupe) as often as every ~300 ms during active use.

One honest caveat

A real share of the "sluggish" feel is renderer-side and Rust won't touch it: the single Zustand store fans every high-frequency event out to ~2k subscriptions, plus multiple live Monaco editors and N WebGL xterm contexts. That needs store-granularity work in TS. Worth separating out so the native work gets judged on what it can actually fix.

---

For what it's worth, herdr's daemon nails the pattern that matters here: a single coalescing dirty-flag + ~16 ms frame pacing + per-client cell-diff so only changed cells cross the wire (its VT layer is Ghostty's libghostty-vt). Happy to write up a Phase-1 design doc for a Rust daemon — protocol, crate choice, node-pty vs portable-pty, and a safe fallback path — or a small prototype behind a flag, whenever the timing's right.

[nwparker]

Thanks @ioitiki !
We're working on the terminal data pane -- or at least experimenting there.

But the other layers are really worth some deep dives. Since you asked, we're happy to have PRs there (if they can gaurantee zero regressions -- that's always the hard part, haha).
Otherwise I'll also dig deeper on those topics. Thanks for brining them up!

[ioitiki]

Following up on the "happy to have PRs there (if they can guarantee zero regressions)" — first one is up: #9312.

It takes the git layer (not the terminal plane you're already experimenting on) and does the smallest useful slice: diff blob reads. Opening a source-control review currently spawns two git show processes per file; this serves those from an in-process gitoxide reader instead. ~11x faster per read in a microbenchmark (native p50 0.26ms vs git show 2.80ms), but speed isn't the point of PR 1 — proving the zero-regression bar is — so most of the work is the safety design:

• Off by default, behind experimentalNativeGit. With the flag off, the native addon is never even loaded — provably inert, zero behavior/latency change.
• The CLI path is never modified. The seam refactor is behavior-neutral, proven by the entire existing src/main/git suite passing with zero test changes.
• A fallback ladder means a user can only ever get slower, never wrong: addon missing / load-fail / native throw / WSL / SSH / post-abort all fall back to the CLI.
• Shadow verification + session poisoning: sampled reads are re-checked against the real git CLI in the background; a single divergence permanently reverts the process to CLI-only for its lifetime. ORCA_NATIVE_GIT=shadow dual-runs every read for dogfooding.
• A differential parity suite runs the native reader against real git byte-for-byte over a fixture matrix (loose+packed objects, CRLF, unicode, binary, empty files, the 10MB boundary, staged-vs-HEAD, linked-worktree index, unmerged paths) — 18 cases, zero divergence, and CI fails loudly if the addon is missing so the gate can't silently vanish.

Native-host only for now (WSL/SSH keep the CLI/relay paths). Scope cuts and the natural next slice (the status-bundle spawn churn from #7576/#7225) are in the PR description. No rush on review given your "concrete Rust work is further off" — mostly wanted to put a concrete, safety-first shape on the table for whenever the timing's right.

[kokotu0]

it costs little heavy but it is enduarable for me.
but if re written by rust, will appear many bug for sure.
so for now it seems incorrect because there are so ferequent updates