多年來，我一直在參與 Rust 和 Rust 社區。我的大部分工作都與創建用于在 Rust 中構建 GUI 工具包的基礎設施有關。然而，我發現我對這種語言越來越失望，我現在太渴望 C++ 的穩定與成熟了！

1、構建系統：Rust 生態小家子氣

Rust 生態系統的局限性之一是 Cargo 構建系統和包管理器的近乎單一文化。雖然在某種程度上使用了其他構建系統（包括集成到更大的多語言項目時的Bazel），但它們并沒有得到工具的很好支持。

相比之下，在 C++ 中，構建系統有很多選擇，允許每個開發人員選擇最適合他們需要的一個。一個非常常見的選擇是 CMake（CMake是一個開源、跨平臺的工具系列，旨在構建、測試和打包軟件，通常用于使用簡單的平臺和編譯器獨立的配置文件控制軟件編譯過程），但也有 Meson、Blaze 及其變體，當然也總是可以求助于 Autotools 并進行制作。如果我們要編譯 AIX 和 DEC OSF/1 AXP 等 Unix 系統，后者尤其有用。如果這些都不夠，還有很多其他選擇，包括 SCons，毫無疑問，我們會定期創建新的選擇。

我們還沒有為 Linebender 項目確定構建系統，但很可能是 CMake，并計劃評估其他系統和遷移，也許是 Meson。

Linebender：包含許多諸如druid、xilem等許多流行的Rust存儲庫。

2、安全：三個原因放棄Rust

這一變化最具爭議的方面可能是放棄了 Rust 語言的安全保證。但是，出于三個原因，我認為這在實踐中不會成為大問題。

首先，我認為自己是一個足夠優秀的程序員，我可以避免編寫有安全問題的代碼。當然，我曾負責過一些 CVE（包括Android 中的字體解析代碼），但我從那次經歷中吸取了教訓，并且有信心在未來避免此類錯誤。

其次，我認為內存安全問題的危險被夸大了。Linebender 項目主要關注 2D 圖形，部分是游戲，部分是用于創建 GUI 應用程序的組件。如果 GUI 程序崩潰，也沒什么大不了的。如果錯誤是由于我們用作依賴項的庫引起的，我們的客戶會明白這不是我們的錯。內存安全錯誤與邏輯錯誤和其他錯誤沒有根本區別，我們只會在它們出現時修復它們。

第三，C++ 語言正在向更安全的方向發展。我們可以使用現代 C++ 技術來避免原始指針的許多危險（盡管字符串視圖可以比它們的支持字符串更長壽，并且 UI 中使用的閉包可以有非常有趣的生命周期模式）。C++ 核心指南很有用，即使它們在違規中受到尊重。而且，正如下一節所討論的，語言本身有望得到改進。

3、語言演化：Rust沒有根本性的新功能

C++ 的一個顯著特征是新功能的快速采用，現在每 3 年有一個新版本。C++20 為我們帶來了模塊，這是一項創新的新功能，我期待著很快就能真正實現這一功能。展望未來，C++26 可能會擁有堆棧協程、嵌入二進制文件內容以初始化數組的能力、安全的基于范圍的 for 循環，以及許多其他好東西。

相比之下，Rust 的創新步伐變得更加穩健。它曾經非常快速，并且異步一直是一項重大努力，但最近登陸的特性（例如通用關聯類型）更像是使現有特性的組合按預期工作，而不是帶來任何根本性的新功能；即將推出的“type alias impl trait”與之類似。在這里，很明顯，Rust 因承諾不破壞現有代碼（由版本機制制定）而受阻，而 C++ 可以自由地在每個新版本中實現向后兼容性破壞性更改。

C++ 有更令人興奮的變化值得期待，包括 Herb Sutter cppfront 提出的潛在新語法，甚至是新的 C++ 兼容 Carbon 語言。

幸運的是，我們在 C++ 社區中擁有出色的領導能力。C++ 之父 Stroustrup 關于安全的論文《A call to action: Think seriously about “safety”; then do something sensible about it 》是一份非常值得一讀的文檔，顯示出對 C++ 面臨的問題的深刻理解，并提出了一個引人注目的未來路線圖。

C++之父去年12月6日發表有關安全的文章