作者 | Tim Anderson

譯者 | 劉雅夢(mèng)

策劃 | 丁曉昀

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

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

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

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

Klabnik 的核心設(shè)計(jì)問題是：“如果 Rust 不試圖與 C 和 C++ 競(jìng)爭(zhēng)最高性能會(huì)怎么樣？”如果我們?cè)敢鉃榱艘子眯远剐阅苌晕⒔档?，但不要太低，?huì)怎樣？”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

會(huì)議推薦

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

今日薦文

你也「在看」嗎？