作者 | Tim Anderson

譯者 | 劉雅夢

策劃 | 丁曉昀

Steve Klabnik 是《Rust 編程語言》的作者，并且在過去的 13 年里對 Rust 項目做出了貢獻(xiàn)，他宣布了 Rue，這是一種系統(tǒng)編程語言，它在沒有垃圾回收的情況下探索內(nèi)存安全性，同時優(yōu)先考慮開發(fā)人員的人機(jī)工程學(xué)，而不是 Rust 的復(fù)雜性。該項目是在 Anthropic 的 Claude AI 的大力幫助下開發(fā)的，目標(biāo)是填補(bǔ)高性能系統(tǒng)語言和垃圾回收替代品之間的未充分服務(wù)的設(shè)計空間。

在使用 Rust 13 周年之際，Klabnik 在一篇博客文章中解釋了他的動機(jī)：

我一直在想我是否應(yīng)該嘗試創(chuàng)造自己的語言。我真的很喜歡它們！這就是為什么我最初參與 Ruby，然后是 Rust 的部分原因！

語言名稱遵循他的“Ru”前綴模式（Ruby、Rust、Rue），同時保持雙重解釋——既是花又是遺憾的表達(dá)。

Klabnik 的核心設(shè)計問題是：“如果 Rust 不試圖與 C 和 C++ 競爭最高性能會怎么樣？”如果我們愿意為了易用性而使性能稍微降低，但不要太低，會怎樣？”

技術(shù)方法的核心是消除 Rust 的標(biāo)志性——借用檢查器?？紤]一個典型的 Rust 代碼，其中你試圖在持有對其中一個元素的引用的同時修改一個向量。編譯器拒絕此操作，因為引用可能會無效。Rue 通過使用“inout”參數(shù)來暫時轉(zhuǎn)移所有權(quán)，從而避免了整個問題，類似于 Swift。在 Rust 中，試圖在迭代當(dāng)量時修改它會在編譯時失敗。Rue 的 inout 參數(shù)允許你臨時傳遞可變引用，但防止將它們存儲在數(shù)據(jù)結(jié)構(gòu)中；在保持內(nèi)存安全的同時，通過更簡單的限制消除了對生命周期跟蹤的需求。

函數(shù)可以就地修改值，但這些值不能作為引用存儲在堆分配的結(jié)構(gòu)中。不需要生命周期注釋。權(quán)衡是什么？某些模式變得無法表達(dá)。正如設(shè)計文檔所承認(rèn)的，Rue 無法支持從其容器借用的迭代器；它們必須消耗它們。

Hacker News 社區(qū)的反應(yīng)既有興趣也有懷疑。一位評論者捕捉到了這個挑戰(zhàn)：

Rust 之所以成功地制造出沒有垃圾回收的內(nèi)存安全語言，是因為它引入了顯著的復(fù)雜性（這是一種權(quán)衡）。沒有人真正知道除此之外的合理方法，除非你還想放棄通用系統(tǒng)編程語言的要求。

根據(jù) GitHub 倉庫中的設(shè)計提案，Rue 實現(xiàn)了四種不同的所有權(quán)模式：值類型、仿射類型、線性類型和引用計數(shù)類型。Klabnik 在回應(yīng)中承認(rèn)，“這必然會導(dǎo)致一些表現(xiàn)力的喪失。沒有萬能的解決方案?！?/p>

開發(fā)方法代表了一個實驗，解決了 Klabnik 多年來一直在思考的 問題：“沒有資金或團(tuán)隊，一個人還能構(gòu)建一門編程語言嗎？”這種方法標(biāo)志著 Klabnik 的轉(zhuǎn)變，他形容自己直到 2025 年都是 AI 懷疑論者。他第一次嘗試在沒有有效利用 AI 的情況下構(gòu)建 Rue，經(jīng)過幾個月的工作后不得不放棄。這一迭代，更有效地使用 Anthropic 的 Claude AI，僅用兩周時間就產(chǎn)生了大約 70,000 行 Rust 編譯器代碼，遠(yuǎn)遠(yuǎn)超過了他之前幾個月的嘗試。

這種協(xié)作超越了典型的編碼協(xié)助。在 Klabnik 和 Claude 共 同署名 的博客文章中，AI 描述了編寫大部分實現(xiàn)代碼，而 Klabnik 指導(dǎo)架構(gòu)并做出設(shè)計決策。Klabnik 強(qiáng)調(diào)，有效使用 AI 工具需要大量的技能：“僅僅知道如何編寫代碼實際上不足以真正使用大模型。它們是它們自己的新類別的工具?！彼姆椒ㄉ婕暗鷮嶒?，編寫簡短的代碼片段，開始對話，并測試不同的提示策略。這種模式是否能消除歷史上資助語言項目的大量投資，還有待觀察。

Rue 仍處于早期開發(fā)階段，具有基本的控制流、函數(shù)和非泛型枚舉。它通過自定義后端而不是 LLVM 編譯為本地可執(zhí)行文件，通過簡化的語義實現(xiàn)快速編譯時間。堆分配正在進(jìn)行中，而語言服務(wù)器協(xié)議支持、包管理和并發(fā)模型尚未實現(xiàn)。該項目使用 Buck2 而不是 Cargo 進(jìn)行未來的編譯器引導(dǎo)。

Klabnik 保持著適度的期望：“我不指望它能發(fā)展成我的業(yè)余項目?！北M管如此，他指出，PHP 和 Rust 的創(chuàng)造者 Rasmus Lerdorf 和 Graydon Hoare 也是從個人實驗開始的。

隨著 AI 輔助開發(fā)工具重塑軟件工程，這項實驗正在進(jìn)行。雖然 GitHub Copilot 和類似的工具協(xié)助增量編碼，Klabnik 使用 AI 進(jìn)行編譯器的架構(gòu)級工作的方法代表了不同級別的合作。如果成功，它可能表明，傳統(tǒng)上需要大型團(tuán)隊的復(fù)雜基礎(chǔ)設(shè)施項目，在 AI 的幫助下，對于熟練的個人來說可能是可行的。

真正的考驗將是那些對 Rust 的學(xué)習(xí)曲線感到沮喪但又不愿意采用垃圾回收機(jī)制的開發(fā)人員是否能接受 Rue 的權(quán)衡。正如一位 Hacker News 評論者所說：

如果他們能在設(shè)計空間中找到一個全新的未被探索的點，我會非常感興趣，但目前，我仍然持懷疑態(tài)度。

Rue 語言的文檔可在 rue-lang.dev 上找到，源代碼在 GitHub 上。

https://www.infoq.com/news/2026/01/steve-klabnik-rue-language-ai/`

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實現(xiàn)技術(shù)價值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點，搶占 2026 智能升級發(fā)展先機(jī)！

今日薦文

你也「在看」嗎？