取代不了 C/C++ 的 Rust 如何「逆襲」？

回憶 Rust 的出現，最初是 Mozilla 為了解決軟體開發中存在的一個問題，即軟體在語言級別上無法真正利用多核計算帶來的性能提升而創建的。不過在後來的發展過程中，很多人經常將其和高性能的 C++ 做對比，甚至不少 Rust 開發者表示，Rust 將取代 C/C++。

但現實來看，Rust 無論是在性能還是語法上均無法比擬 C/C++，除此之外，Rust 內部管理也比較混亂，而近日，Rust 核心團隊更是為了整肅 Rust，發布了 2019 年 Rust 路線圖。

作者 | Rust 核心團隊

譯者 | 彎月

責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

每年 Rust 社區都會聚在一起制定總規劃。今年除了調查問卷之外，Rust 團隊還在 12 月舉行了博客文章徵集活動，並在幾個星期內收集到了 73篇博客文章。最近，其將這些信息融合到一起，總結出了 2019 年的總規劃RFC（https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md）。

接下來，這篇文章將介紹其中的一些重點。

主題：成熟

簡單來說，2019年是Rust項目注入活力並走向成熟的一年。去年我們發布了許多東西，而且也成長了許多。現在需要反過來充實現有的內容，並為未來做準備。

今年，我們計劃的工作內容主要分為三大類：

• 加強管理：改進項目運作的方式；
• 處理積壓已久的請求，完成那些我們已經動手做但還沒有做完的工作；
• 改進：改進語言和工具的整體質量。

加強管理

在過去三年中，Rust項目成長了許多。以前Rust的核心團隊只有8名成員組成。2015年我們增加了子團隊，發展到了23人。現在我們已經超過了100人，規模比許多公司都大！當然，除了團隊之外，Rust社區的規模也有所擴張。然而，在發展的同時，我們發現以前在小項目時代運作良好的流程現在開始拖後腿了。

許多團隊都發布了計劃，準備改善流程。一般來說，我們只需要簡單地把之前不成文的規定正式地寫下來，但有時候也需要建立新的流程。

由於許多人對項目管理感興趣，所以我們還成立了新的「管理工作組」。這個工作組將專註於與各個團隊合作，改善管理的流程，並推進各個團隊之間傳播經驗和策略。

此外，RFC流程曾經非常適合Rust，但隨著我們的成長，有時候也會遇到RFC不合適的情況。今年我們也會考慮改進該流程。

積壓已久的請求

我們有許多非常有意思的提議都處於待定的狀態，主要的設計已經做完，但由於種種複雜的原因，我們一直沒有時間處理這些請求。今年我們希望能重新審視這些問題，並努力解決這些積壓已久的問題。

這些工作包括：

• Cargo團隊和自定義註冊項；
• Language團隊在審查async/await、專有化、常量泛型，以及泛型關聯類型；
• Libs團隊希望完成自定義分配器。

改進

最後，近年來我們也做了許多基礎的工作。例如，編譯器大部分被重構，可以支持增量編譯，並更好地適應IDE。現在這些部分都已經完成，我們希望能「改進」這些工作，以提供最好的體驗。

比如：

• 編譯時間和IDE支持；
• 改進語言標準，如改進參考手冊，並編寫不安全代碼指南；
• WebAssembly工作組今年的工作包括打磨wasm的支持，如調試。

對於 Rust 的未來，網友並不一致

這篇文章只介紹了Rust 2019的部分計劃。不過基於此，網友對其看法不一：

評論1：Rust項目最讓人擔心的問題就是他們的管理越來越混亂。我喜歡的每一門語言都由一名BDFL（終身仁慈獨裁者）負責協調，而那些設計得不太好的語言（C++、Java）恰巧都是通過協作的方式管理的。如果Rust項目由工作組來做決策，怎樣保證它不會誤入歧途呢？

評論2：語言本身仍然主要由語言團隊負責設計，該團隊的人數並不多。如果非要說團隊膨脹，也是因為我們認為Rust不僅僅是語言。你喜歡的那些由BDFL設計的語言，也不是由BDFL做出一切決定，比如包管理器、網站、文檔、甚至會議。這些都不是一個人的力量能夠完成的。

我們的核心團隊會提供所有的高層觀點，以保證各個團隊的協調。

評論3：當初由BDFL設計時，JavaScript非常糟糕，後來在大型社區接管後，就變成了優秀語言。

雖然JavaScript不是最好的語言，但目前來看它比許多類似的語言（如Python或Ruby等）都好，它有優秀的非同步處理，優秀的類型系統，優秀的模塊系統，也不存在幾十年之久的版本危機。

原文：https://blog.rust-lang.org/2019/04/23/roadmap.html

本文為CSDN翻譯，轉載請註明來源出處。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！