用Rust和C++代碼編譯時間同樣糟糕嗎？

Rust 官方正在討論為 Rust 提供 interoperable_abi features gate

interoperable_abi[1] 意味著提供一個新的 Rust ABI extern "interop" 和 repr(interop) ，用于實現(xiàn)有安全數(shù)據(jù) 類型的高級編程語言之間的互操作性。

動機摘要：

目前 Rust ABI 并不穩(wěn)定，多語言交互只能通過 C-ABI 來進行。但是這限制了在 ABI 之間使用更高級的安全類型?？苫ゲ僮鞯?ABI 將定義一種標準方法來跨高級語言進行調(diào)用，傳遞高級數(shù)據(jù)類型，而不需要將其降級為 C-ABI。該 ABI 將與任何提供C 兼容 FFI 的語言（包括 C本身），并且語言還可以為可互操作的 ABI 添加特定的更高級別的支持?？苫ゲ僮鞯?ABI 旨在成為靜態(tài)和動態(tài)形式的編譯庫（包括系統(tǒng)庫）的合理默認值。

可互操作的 ABI 將是 C ABI 的嚴格超集。

可互操作 ABI 不支持的內(nèi)容摘要：

可互操作的 ABI 并不旨在支持整個Rust 標準庫.

可互操作的 ABI 不會旨在支持復雜的生命周期處理

可互操作的 ABI（至少在第一個版本中）不會以源代碼或編譯形式提供接口描述語言（IDL）

可互操作的 ABI 的目的不是在不同語言的表示之間提供“翻譯”

可互操作的 ABI 不能支持任意的編譯時泛型函數(shù)

GCC-rs 項目在 2022 年取得了很大進展

gccrs是一個旨在為 GNU Compiler Collection 帶來對 Rust編程語言的支持的項目。其目標是從頭開始為 Rust 編程語言編寫一個新的編譯器前端，將該前端集成到 GCC 中，使其作為一種語言與 C、C++、Ada、D、Go 一起使用。

該項目最初于 2014 年啟動。當時，Rust 尚未實現(xiàn)穩(wěn)定版本（Rust 1.0 于 2015 年 5 月發(fā)布），對于單個開發(fā)人員來說很難跟上高強度的變化。2019年又開始努力，此后一直在穩(wěn)步進行。

2020 年，菲利普·赫倫 ( Philip Herron )開始獲得資金支持，隨后他得以開始全職從事該項目。此贊助來自 Open Source Security公司。

Philip 受雇于 Embecosm 并從他們的管理中受益，并得到 GCC 指導委員會的支持。2022 年，在將近一年半的單飛之后，Philip 加入了另一位由 Open Source Security 公司資助的全職工程師 Arthur Cohen ，也受雇于 Embecosm。現(xiàn)在有兩名工程師每周為該項目投入 40 小時。

2022 年發(fā)生的最引人注目的事件是將 gccrs 合并到 GCC，gccrs 將在 2023 年 4 月發(fā)布的 GCC 13.1 版本中可用。

更多內(nèi)容參考 gccrs 2022 年報[2]

“

P.S 與 gccrs 對應的是另一個項目 rustc_codegen_gcc。它是作為 Rust 編譯器 GCC 后端，目前也正在積極開發(fā)中，感興趣可以關注rustc_codegen_gcc：進度報告#19[3]。

用 Rust 和 C++ 代碼編譯時間同樣糟糕嗎？

原文[4]作者寫道：

“

C++ 因其緩慢的構建時間而臭名昭著。“我的代碼正在編譯”是編程世界中的一個梗，而 C++ 讓這個笑話流傳開來。

“

像 Google Chromium 這樣的項目 在全新硬件上構建需要一個小時，在舊硬件上構建需要 6 小時。即使有數(shù)千美元的云計算能力，Chromium 構建時間仍然在六分鐘左右。這是我完全不能接受的。人怎么可以每天這樣工作？

作者也聽說，Rust 也面臨相同的問題，但他有實證精神，親自動手證明一下 Rust 是不是和 Cpp 一樣很慢。

這是他的計劃：

查找開源 C++ 項目。

從項目中提取一部分為迷你項目中。

將 C++ 迷你項目的代碼逐行重寫為 Rust。

優(yōu)化 C++ 項目和 Rust 項目的構建工具鏈。

比較兩個項目之間的編譯+測試時間。

經(jīng)過這樣的測試，作者得出最終結論：

編譯時間是 Rust 的問題嗎？是的。有一些提示和技巧可以加快構建速度，但作者沒有找到神奇的數(shù)量級改進，否則作者將很高興使用 Rust 進行開發(fā)。

Rust 的構建時間和 C++ 一樣糟糕嗎？是的。對于更大的項目，Rust 的開發(fā)編譯時間比 C++ 更短，至少作者的代碼風格是這樣。

對于完整構建，C++ 構建花費的時間與 Rust 相比，大致相同（17k SLOC）或花費更少的時間（100k+ SLOC），而不是更長。

對于增量構建，與 C++ 相比，Rust 構建有時更短，有時更長（17k SLOC）或更長（100k+ SLOC），但并不總是更長。

很欣賞 Rust 的工具鏈（尤其是 Cargo、rustup 和 miri）。

應用實踐

Gama 發(fā)射的太陽帆宇宙飛船中使用了 Rust

Gama[5] 將發(fā)射太陽帆宇宙飛船，并且是公開將 Rust 送入太空的公司之一。提供軟件服務的應該是這家公司：Tweedegolf[6] ，該公司也是 Rust 基金會銀牌會員。他們的開源倉庫[7]里有一個 Rust 實現(xiàn)的 PTP (精確時間協(xié)議) 庫，這個PTP一般用在衛(wèi)星的時間源，比NTP更精確。但這個是 PoC 實現(xiàn)，不知道這次發(fā)射的飛船上有沒有用。從另外的項目 嵌入式開發(fā)板 pcf85063a （一般用于計時鬧鐘）rust 驅(qū)動來看，這次上天的 Rust 程序很可能和精確計時相關。

Gama 太陽帆的衛(wèi)星于 2023 年 1 月 3 日由 SpaceX 獵鷹 9 號成功送入軌道[8]。

生態(tài)看點

svix-webhooks：企業(yè)級 Webhooks 服務

svix-webhooks[9] 是基于 Rust 實現(xiàn)的企業(yè)級 Webhooks 服務器。Svix 使開發(fā)人員可以輕松發(fā)送 webhook。開發(fā)人員進行一次 API 調(diào)用，Svix 負責可交付性、重試、安全性等。

turmoil：開發(fā)和測試分布式系統(tǒng)的框架

Tokio 發(fā)布了[10]用于開發(fā)和測試分布式系統(tǒng)的框架 turmoil[11] 的初始版本。

測試分布式系統(tǒng)很難。不確定性無處不在（網(wǎng)絡、時間、線程等），使得難以實現(xiàn)可重現(xiàn)的結果。由于部署，開發(fā)周期很長。所有這些因素都會減慢開發(fā)速度，并且難以確保系統(tǒng)的正確性。turmoil力求通過模擬主機、時間和網(wǎng)絡來解決這些問題。這允許整個分布式系統(tǒng)在單個線程的單個進程中運行，從而實現(xiàn)確定性執(zhí)行。

cargo-sandbox 發(fā)布

cargo-sandbox[12] 打算成為 cargo 的一個近乎直接的替代品。關鍵的區(qū)別在于，cargo-sandbox 在 docker 容器中運行相關命令，目的是將潛在的惡意代碼與主機環(huán)境的隔離開來（關于威脅模型的更多細節(jié)，見README）。其目標是盡可能地接近 "100%"的兼容原版 cargo，并獲得最順暢的體驗。

Rust 中的深度學習：Burn 0.4.0 發(fā)布以及 2023 年的規(guī)劃

Rust 深度學習框架Burn[13] 0.4 完成了后端重構，除此之外，還實現(xiàn)了很多新的功能，如ADAM優(yōu)化器、轉(zhuǎn)化器模塊等。下一個重點將是增加視覺相關的模塊，如卷積和池化層。

shura-一個安全的2D 游戲引擎，易于創(chuàng)建易于管理的游戲

shura[14] 是rust編寫的一個安全，快速并且跨平臺的游戲框架。shura使用一個2D組件系統(tǒng)、場景管理和group系統(tǒng)幫你管理一個大型游戲。

shura主要的目標是，你的游戲邏輯可以分別放在不同的組件、group和場景中。

rumqtt: 構建 mqtt 的 Rust 生態(tài)

rumqtt[15] 是一組用 rust-lang 編寫的開源庫，用于實現(xiàn) MQTT 標準，同時力求簡單、健壯和高性能。

rumqtt 是 Bytebeam 物聯(lián)網(wǎng)咨詢公司開源的 MQTT 代理。rumqtt 目前版本已經(jīng)發(fā)布到了 R19 版，并未按語義化版本來發(fā)布。

目前發(fā)布了 R19 新版本：

新的版本提升了性能和可靠性（可以支持 多達10,000 多個 MQTT 客戶端，使用 mqttwrk[16] 進行基準測試）

添加了一個用于測試 rumqttd 的公共服務器

添加了 Prometheus 集成和其他優(yōu)化更改

加了對存儲支持的持久性的實驗性支持，以確保消息的零數(shù)據(jù)丟失

rumqtt 在 2023 年初推出對 MQTT v5 的支持。

審核編輯：劉清