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

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

動(dòng)機(jī)摘要：

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

可互操作的 ABI 將是 C ABI 的嚴(yán)格超集。

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

可互操作的 ABI 并不旨在支持整個(gè)Rust 標(biāo)準(zhǔn)庫(kù).

可互操作的 ABI 不會(huì)旨在支持復(fù)雜的生命周期處理

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

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

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

GCC-rs 項(xiàng)目在 2022 年取得了很大進(jìn)展

gccrs是一個(gè)旨在為 GNU Compiler Collection 帶來(lái)對(duì) Rust編程語(yǔ)言的支持的項(xiàng)目。其目標(biāo)是從頭開始為 Rust 編程語(yǔ)言編寫一個(gè)新的編譯器前端，將該前端集成到 GCC 中，使其作為一種語(yǔ)言與 C、C++、Ada、D、Go 一起使用。

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

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

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

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

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

“

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

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

原文[4]作者寫道：

“

C++ 因其緩慢的構(gòu)建時(shí)間而臭名昭著?！拔业拇a正在編譯”是編程世界中的一個(gè)梗，而 C++ 讓這個(gè)笑話流傳開來(lái)。

“

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

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

這是他的計(jì)劃：

查找開源 C++ 項(xiàng)目。

從項(xiàng)目中提取一部分為迷你項(xiàng)目中。

將 C++ 迷你項(xiàng)目的代碼逐行重寫為 Rust。

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

比較兩個(gè)項(xiàng)目之間的編譯+測(cè)試時(shí)間。

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

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

Rust 的構(gòu)建時(shí)間和 C++ 一樣糟糕嗎？是的。對(duì)于更大的項(xiàng)目，Rust 的開發(fā)編譯時(shí)間比 C++ 更短，至少作者的代碼風(fēng)格是這樣。

對(duì)于完整構(gòu)建，C++ 構(gòu)建花費(fèi)的時(shí)間與 Rust 相比，大致相同（17k SLOC）或花費(fèi)更少的時(shí)間（100k+ SLOC），而不是更長(zhǎng)。

對(duì)于增量構(gòu)建，與 C++ 相比，Rust 構(gòu)建有時(shí)更短，有時(shí)更長(zhǎng)（17k SLOC）或更長(zhǎng)（100k+ SLOC），但并不總是更長(zhǎng)。

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

應(yīng)用實(shí)踐

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

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

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

生態(tài)看點(diǎn)

svix-webhooks：企業(yè)級(jí) Webhooks 服務(wù)

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

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

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

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

cargo-sandbox 發(fā)布

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

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

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

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

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

shura主要的目標(biāo)是，你的游戲邏輯可以分別放在不同的組件、group和場(chǎng)景中。

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

rumqtt[15] 是一組用 rust-lang 編寫的開源庫(kù)，用于實(shí)現(xiàn) MQTT 標(biāo)準(zhǔn)，同時(shí)力求簡(jiǎn)單、健壯和高性能。

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

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

新的版本提升了性能和可靠性（可以支持 多達(dá)10,000 多個(gè) MQTT 客戶端，使用 mqttwrk[16] 進(jìn)行基準(zhǔn)測(cè)試）

添加了一個(gè)用于測(cè)試 rumqttd 的公共服務(wù)器

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

加了對(duì)存儲(chǔ)支持的持久性的實(shí)驗(yàn)性支持，以確保消息的零數(shù)據(jù)丟失

rumqtt 在 2023 年初推出對(duì) MQTT v5 的支持。

審核編輯：劉清