我之前寫過關於Rust 的未來的文章，看來沒人阻止我再寫一篇！恰恰相反：這次 Rust 核心團隊甚至主動發出了邀請。我雖然有點遲到了，但以下是我對 2018 年 Rust 優先事項的一點淺見。

這傢伙到底是誰？

我們很可能從未見過面——這實在有點可惜，令人沮喪的是機率還很高。先說明一下背景：我來自 Python 和 PHP 這類動態型別語言。Rust 是第一個讓我能夠撰寫真正底層程式碼，卻又不會有像在跟夜店保鑣爭論那種感覺的語言。

對我而言，Rust 不是火焰花，而是我個人的專屬大獸神¹。我希望 Rust 能夠成功，但為此我們還有幾個待辦事項需要完成。

更完善的編譯器文件，讓貢獻更輕鬆

當我在俄亥俄州哥倫布參加Rust Belt Rust時，遇見了Niko Matsakis（尼可・馬薩克斯）、Ariel Ben-Yehuda（艾瑞爾・班-耶胡達）和Santiago Pastorino（聖地牙哥・帕斯托里諾）。這幾位優秀的先生在 impl 期間熱切地投入non-lexical lifetimes（非詞彙生命週期）的開發。看著他們埋頭鑽研編譯器，對我來說深具啟發，讓我開始思考自己是否也能做出貢獻。不用說，要投入編譯器的開發，入門門檻可能相當高。我目前還沒有做出任何貢獻。

我很希望能利用零碎的 30 到 60 分鐘時間，隨手修復編譯器中的一些小問題。可能只是重新命名一個變數、撰寫一個測試，或是補上一段文件。因此，我的第一個願望是，讓對這個語言的貢獻變得更容易。這可以透過提供更全面的指導、更多適合新手的工單，以及更完善的編譯器文件來實現。這些都已經由尼可提出過了。

給中階程式設計師的更多資源

相關地，我也希望看到更多針對中階 Rust 程式設計師的演講、指南和書籍。這包括如何用 Rust 建構大型專案的討論，以及 Rust 特有的design patterns（設計模式）。我想要閱讀更多關於 Rust 在專業領域的應用，並看到來自不同產業的案例研究。舉例來說，有一家名為 snips.ai 的新創公司，使用 Rust 打造了裝置端的語音助理。他們整合了 C 與 C++ 函式庫，而我想更深入了解他們的歷程。

改善 RFC 流程

我試著非常緊密地追蹤 RFC 流程，但我的時間有限。我的願望是，我打開任何一份 RFC 都能立刻掌握它的狀態：

• 討論的摘要，包含主要的優缺點。
• 一個簡潔的使用範例，就放在開頭。
• 邁向穩定化的下一步。

舉例來說，如果我查看這個（並非）隨機挑選的議題，我甚至不知道該從何看起。目前最大的阻礙是什麼？誰正在積極推動這件事？我能如何幫忙？

GitHub 對於程式碼來說很棒，但關於新功能的討論常常失控。這也不是僅限於 Rust 的問題。看看其他大型專案就知道了，像是 Docker、Kubernetes 或 Node。或許我們需要一個新的工具來處理這個問題。

老面孔

如果我能在 2018 年要求兩個穩定功能，那會是? 在 main 中和non-lexical lifetimes。

當然還有更多可以提的，但我就不拿更快的編譯時間、impl trait、generators（生成器）等來煩你了。我們在這方面已經走在正確的道路上，請改看Nick Cameron（尼克・卡麥隆）的文章吧。

我深信，透過改善文件與指導制度，我們今年就能大幅增加貢獻者的人數，並讓許多備受期待的功能趨於穩定。

^{1. 聲明：我從來沒看過任何一集 Power Rangers。↩}