Systemd has merged support for writing parts of itself in Rust, with a hard boundary around where the language can be used: only new leaf components, no porting of existing C code, and nothing that other components depend on. Systemd maintainer Christian Brauner announced that he had merged the change, and LWN.net reported it on 26 October.
The scope restriction is the substance of the story. A "leaf component" in systemd terms is code at the edge of the dependency graph — invoked by other parts, but never depended upon by them. Brauner's stated rule is that Rust will be used only for new leaf components; existing C code is not being rewritten, and nothing in the dependency path of other components will be written in Rust. That boundary keeps Rust well away from PID 1, systemd's init process, which sits at the base of the dependency tree for essentially everything else on the system.
The two historic objections to embedding Rust in a large C project were friction at the C/Rust interface — ABI and FFI complexity — and the risk that adopting the language would cascade into a project's core. A leaf-only policy neutralises both. The interface surface stays small because leaf components are called, not called through, and dependency risk is pushed to the edge by construction.
For maintainers and downstream packagers, the practical consequence is not a code change but a toolchain change. Building systemd now effectively requires a Rust compiler on build hosts, and reproducible-build environments would need it version-pinned. Cross-compilation setups, hardened build sandboxes, and minimal build containers that previously needed only a C toolchain would have to account for an additional language runtime in the build graph — a supply-chain consideration in itself, since the Rust toolchain and its crates become inputs that must be tracked, verified, and pinned like any other.
That is the angle most relevant to infrastructure teams: SBOM and supply-chain hygiene work typically assumes a compiler inventory. A new language dependency implies crate-level provenance, toolchain provenance, and updated build attestation all enter the picture for a component as widely deployed as systemd.
The precedent also cuts both ways. Systemd is adopting Rust incrementally rather than translationally — additive new code at the edges, explicit boundaries, no sweeping rewrite, in line with the direction the Linux kernel has taken. For other long-lived, C-heavy infrastructure projects evaluating the same move, this provides a reusable template: start with components nobody depends on, keep the blast radius away from the critical path, and let the policy prove itself over release cycles. If leaf components ship cleanly without burdening packagers, expect imitation; if they don't, the policy reads as a boundary rather than a blueprint.
The announcement also lands in the shadow of the kernel's own, far more contested, introduction of Rust. Systemd's much narrower, edge-first approach sidesteps most of that terrain by design — and its success or friction will be watched by other C-heavy projects weighing a similar step.
For IT professionals managing Linux fleets, Rust's entry into systemd's build is a dependency-management and reproducibility problem before it is a programming-language question.
Source: LWN.net, "Systemd adds support for components written in Rust".
Systemd 已合併以 Rust 編寫部分自身的支援，並對該語言的使用範圍劃下嚴格界線：僅限新增的葉節點元件（leaf component），不得移植現有 C 代碼，亦不可用於其他元件所依賴的部分。Systemd 維護者 Christian Brauner 宣布已合併該項變更，LWN.net 於 10 月 26 日報道。
範圍限制正是這則新聞的核心。在 Systemd 的語境中，「葉節點元件」指處於 dependency graph 邊緣的代碼 — 由其他部分呼叫，但自身不被任何部分依賴。Brauner 明確定下的規則是：Rust 僅用於新增的葉節點元件；現有 C 代碼不會重寫，其他元件 dependency path 上的任何部分亦不會以 Rust 編寫。這條界線使 Rust 遠離 PID 1，即 systemd 的 init 進程 — 該進程位於系統中幾乎所有其他組件之 dependency tree 的根基。
過去將 Rust 嵌入大型 C 專案的兩項主要反對意見，分別是 C／Rust 介面的摩擦（ABI 及 FFI 的複雜性），以及採用該語言可能蔓延至專案核心的風險。「僅限葉節點」的政策一舉化解了兩者。由於葉節點元件是被呼叫而非呼叫他人，介面表面得以保持細小；dependency 風險亦從結構上被推至邊緣。
對維護者及下游打包者而言，實際影響並非代碼變更，而是 toolchain 變更。現時建置 systemd 實質上需要在 build host 上配備 Rust 編譯器，而 reproducible-build 環境亦須將其版本鎖定。交叉編譯設定、加固的 build sandbox，以及過往只需 C toolchain 的精簡 build container，則須在 build graph 中納入額外的語言 runtime — 這本身就是一項供應鏈考量，因為 Rust toolchain 及其 crates 已成為必須像其他輸入般追蹤、驗證及鎖定的項目。
這正是與基礎設施團隊最息息相關的角度：SBOM 及供應鏈衛生（supply-chain hygiene）工作通常以編譯器清單為前提。對於像 systemd 這樣部署廣泛的元件，新增的語言依賴意味著 crate 層面的來源追溯、toolchain 來源追溯，以及更新的 build attestation 均須納入考慮。
此先例亦具雙向影響。Systemd 正以漸進方式而非整體移植方式採用 Rust — 在邊緣加入新代碼、設明確界線、不做大規模重寫，與 Linux kernel 所走的方向一致。對於其他長期運作、以 C 為主的基礎設施專案而言，若正評估同類舉動，這提供了一個可重用的範本：從無人依賴的元件開始，將 blast radius 隔絕於關鍵路徑之外，讓政策在多個 release cycle 中自行證明其成效。若葉節點元件順利發布而不加重打包者負擔，可預期會有人仿效；若未能如此，該政策便只會被視為一道界線，而非一份藍圖。
是次宣布亦落在 kernel 當年引入 Rust 那場爭議遠為激烈之事的陰影之下。Systemd 採取範圍遠為收窄、邊緣先行的方法，從設計上避開了大部分爭議地帶 — 其成功與否或出現的摩擦，將受到其他權衡類似步伐的 C 為主專案密切注視。
對管理 Linux 機群的 IT 專業人士而言，Rust 進入 systemd build 首先是一個 dependency 管理及可重現性問題，其次才是程式語言問題。
來源：LWN.net，〈Systemd adds support for components written in Rust〉。