Should OrbitService Be Rust?

Short answer: yes, but not as "port OrbitService". That framing produces a two-year rewrite of code that already works. The useful framing is that OrbitService is eight loosely-coupled things wearing one binary's name, Rust's advantage over each of them ranges from large to actively negative, and two of them should stay C++ permanently. The order matters more than the decision.

The port already started

The interesting fact about this question is that it is not hypothetical. OrbitService already links two Rust static libraries and ships them.

third_party/py-spy-ffi is a rust_static_library in LinuxTracing's dependency list. When Orbit samples a Python call stack, that stack is walked by Rust reading another process's memory through ptrace. It has been there long enough to be unremarkable.

src/OrbitLiveViewer is newer and more consequential. It is a six-crate Cargo workspace — orbit-live-event, -ring, -protocol, -render, -server, -ffi — compiled by Bazel into liborbit_live_ffi.a and linked into OrbitService. It runs the HTTP and WebSocket server, owns the event ring buffer, and defines the event vocabulary the browser viewer consumes.

So the questions people usually spend six months answering are already answered here:

• rules_rust 0.73 is in MODULE.bazel, with two independent crate_universe repositories resolved from checked-in Cargo.lock files.
• Bazel downloads the Rust toolchain itself. A contributor still needs nothing installed — that was the whole point of the Bazel port.
• Rust and C++ objects link into one binary, on Linux, in CI, today.
• There are already 68,431 lines of Rust in the tree.

The remaining question is not can we. It is which parts, in what order, and what does the boundary cost while we are mid-way.

What the service actually is

"OrbitService" is a convenient name for a binary that does eight barely-related jobs. They have wildly different portability profiles, and lumping them together is what makes the question look intimidating.

The case, both ways

Where the safety pitch is weaker than advertised

The standard argument for porting a C++ backend is data races. It is worth checking whether it applies here before leaning on it, because in this codebase it mostly does not.

The capture pipeline is not a thread soup. TracerImpl runs two threads: Tracer::Run, which polls every per-CPU ring buffer in one loop, and Proc.Def.Events, which drains deferred events. There is exactly one absl::Mutex between them, and it is annotated. GrpcClientCaptureEventCollector adds a sender thread behind one fully-annotated mutex. The design is a pipeline of single-threaded stages with explicit handoffs — which is to say, it is already the shape Rust would push you toward.

So the honest version is: Rust would make 43 unannotated service-side mutexes compiler-checked, and that is a modest win, not a dramatic one. Anyone selling this port on fearless concurrency is selling the wrong feature.

The safety argument that does hold is narrower and stronger: this service parses untrusted, externally-shaped binary data in two hot places — kernel ring-buffer records and arbitrary object files. That is exactly the workload where a bounds-checked slice is worth more than a code review, and it is why ObjectUtils ranks first below rather than LinuxTracing.

The seam is the whole cost

Every incremental port is really a bet about the boundary. The reason the live viewer landed cleanly is not that Rust is good; it is that the boundary was chosen where the data flow was already narrow, one-directional and made of plain integers.

What Rust deletes from the build

This is the part of the case that is concrete and easy to verify. Every C++ dependency the service carries has a mature pure-Rust counterpart, and in several cases the counterpart is what the rest of the profiling world already uses.

The LLVM row is the one that matters most. The Bazel port needed two separate patches to LLVM 17 just to build it, and it is the largest single compile in the tree. Deleting six LLVM libraries in exchange for four pure-Rust crates removes a patch directory, a version pin that only exists because the registry has nothing newer, and a meaningful slice of cold-build time.

The parts that should stay C++

Three components should not be ported, and the reason is the same for all three: they execute inside a process Orbit does not own.

The same argument, weaker but still decisive, covers liborbit.so — the manual-instrumentation library a user links into their application — and OrbitVulkanLayer, which the graphics driver loads into any Vulkan process. Both must be small, must not perturb the host, and must be loadable next to arbitrary third-party code. 503 lines of C++ with no runtime is the correct answer and will stay the correct answer.

The trampoline writer is a separate case with the same conclusion. Trampoline.cpp disassembles a function prologue, relocates the displaced instructions, and writes machine code into another process's address space. Rust offers nothing there: every line is unsafe by construction. You would trade eleven reinterpret_casts for eleven unsafe blocks and gain no checking, while taking on the risk of reproducing 17 test files' worth of x86-64 encoding edge cases. (iced-x86 is genuinely better than capstone at instruction relocation — but that is an argument for a bindings-level change, not a port.)

Ranking the eight

Plotting each component on what Rust actually buys against what it costs to get there sorts the question out faster than any amount of prose.

A sequence that ships

Four tiers. Each one is independently useful, each one can be stopped after, and none of them requires the next to be worth doing.

The wire format is the real boundary

Everything above puts the seam through the process: some modules C++, some Rust, an ABI between them. There is a better place to put it, and the tree is already most of the way there. Put the seam in the wire format and the language question largely dissolves — the C++ service becomes one producer among several rather than the system's centre, and a Rust collector replaces it piecemeal by speaking the same protocol. No FFI, no shared types, no seam.

orbit-live-protocol already does this for the live path, and it does it without protobuf. LiveEvent is #[repr(C)], 32 bytes, little-endian, fixed layout. Frames are magic, version, type, length. The browser reads them with a DataView and no library — no grpc-web proxy, no protobuf-js, no codegen step.

So the question is whether that generalises from six live event kinds to the thirty-nine variants of ClientCaptureEvent. It does — but not by making all thirty-nine POD. The format should follow the frequency.

The mechanism that makes the hot lane possible is already in both schemas: hoist the variable-length part out of the record and reference it by id. CallstackSample carries a callstack_id and the frames live in InternedCallstack; LiveEvent carries a name_id and the text lives in an InternedString frame. Once that is done, protobuf is varint-wrapping records that are already fixed-shape and length-prefixing tables that are already append-only. It is pure overhead on both.

What protobuf is actually buying

Two of these are real and need answers. Two do not survive contact with the tree.

Set against that: dropping gRPC removes protobuf 36, gRPC 1.83, c-ares, and the entire BoringSSL-versus-OpenSSL conflict that took three attempts to resolve during the Bazel port. That is a larger win than the wire-format performance, and it is certain rather than projected.

Five things to fix in LiveEvent first

If this envelope grows to carry the whole capture stream, its cracks stop being cosmetic. All five are cheap to fix now and expensive to fix later.

1. Rename _pad. It is a field, not padding, and its current name is an invitation to zero it during a refactor.
2. Give each kind a typed payload. Keep the 32-byte envelope, but define per-kind #[repr(C)] payload structs viewed from the tail rather than reinterpreting duration_ns by convention. bytemuck or zerocopy give FromBytes/AsBytes derives with compile-time layout checks, so no unsafe appears in Orbit's own code.
3. Stop encoding field by field. encode_frame currently runs payload.extend_from_slice(&ev.as_bytes()) per event, and as_bytes does eight separate to_le_bytes calls. Every target Orbit ships is little-endian: assert it with a #[cfg(target_endian)] compile error and cast_slice the whole batch in one extend_from_slice. On the wasm side it becomes a typed-array view with no copy at all.
4. Cap FunctionCall's registers inline. repeated uint64 registers is the one genuinely variable field in the hot lane. It holds the SysV argument registers, so six inline slots covers it — no side table needed.
5. Let a batch identify itself. Status carries counters, but an EventBatch has no sequence number or base timestamp, so a client that reconnects cannot tell what it missed. One u64 fixes it.

Sequencing

Land the three-lane split in the live protocol first. It is first-party, already versioned, and has no external consumers — the cheapest possible place to be wrong. gRPC stays as the legacy transport for the Qt client until the Qt client goes away, which is the same gate as everything else in this document and for the same reason.

The .orbit container gets the same three lanes, and the existing protobuf reader becomes an import path for old captures. That is bounded work with a defined end, not a second format to maintain.

What this changes about the rest of the analysis is the framing. The project stops being "port the C++ service to Rust" — with its FFI seam, its two protobuf universes, and its per-event marshalling cost — and becomes "define the protocol, then write a collector that speaks it." The C++ service keeps working as one producer against that protocol for exactly as long as it needs to, and nothing has to be ported in place.

What would make this wrong

Three things would change the ranking, and it is worth naming them so they can be watched for rather than argued about.

If the Qt client is retired sooner than expected, the Tier 1 gate disappears and ObjectUtils, CaptureFile and GrpcProtos stop having C++ consumers at all. That would move the whole sequence forward by however long the client survives, and would also make the "two protobuf universes" objection evaporate — there would only be one, and it would be prost's.

If the wire format lands first, the tier list above stops being the plan and becomes a fallback. That case is made in its own section because it turned out to be the stronger argument: a protocol boundary costs no FFI, forces no shared types, and lets the C++ service keep running unmodified while a Rust collector grows beside it. The risk is the reverse of a port's — not that the migration stalls half-done, but that two collectors both work and neither is retired.

If a capture-correctness bug traces to a memory error in the C++ parsers, Tier 1 becomes Tier 0. That is the one class of failure where this port stops being an engineering preference and starts being a fix.

In one paragraph

Porting OrbitService to Rust is worth doing, is already a third started, and is a bad idea as a project. The parts of the service where Rust wins decisively — parsing binaries that the user's toolchain produced and the kernel's variable-length records — are also the parts that are smallest, most isolated, and easiest to test, so they should go first and they will pay for themselves. The parts that would be a heroic rewrite are the unwinder and the trampoline writer, neither of which becomes safer in Rust, one of which changes the profiler's output. And the code that runs inside the program being profiled should stay 503 lines of C++ with no runtime for as long as Orbit exists. The correct project is not "port the service"; it is "settle the protocol, then keep growing the Rust half along the seams that are already narrow" — which, protocol aside, is what the last few months of commits have been doing anyway.