我以前寫過關於Rust 的未來的文章，看來也沒人阻止我再寫一次！恰恰相反：這次 Rust 核心團隊甚至主動邀請大家這麼做。雖然我有點晚才跟上，但這裡還是分享一下我對 2018 年 Rust 優先事項的一點淺見。

這傢伙到底是誰？

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

對我來說，Rust 不是fireflower，而是我專屬的Megazord¹。我希望 Rust 能夠成功，但要達成這個目標，我們還有幾件事得先完成。

更容易參與貢獻的編譯器文件

當我在俄亥俄州哥倫布參加Rust Belt Rust 時，遇到了Niko Matsakis、Ariel Ben-Yehuda 和Santiago Pastorino。這幾位優秀的紳士在 impl 期間熱情地投入non-lexical lifetimes 的開發。看著他們埋頭鑽研編譯器，讓我深受啟發，也開始思考自己是否也能貢獻一份心力。不用說，要投入編譯器開發的門檻其實相當高。我到目前為止還沒有做出任何貢獻。

我很希望能利用零碎的 30 到 60 分鐘，隨手修一下編譯器裡的小問題。可能只是重新命名一個變數、寫個測試或是補上一段文件。因此，我的第一個願望是，希望對語言本身的貢獻能變得更容易。這可以透過更完善的指導制度、更多適合新手的任務，以及更好的編譯器文件來達成。這些其實都已經是Niko 提過的建議。

給中階開發者的更多資源

相關地，我也希望看到更多針對中階 Rust 開發者的演講、指南和書籍。這包括如何用 Rust 組織大型專案的討論，以及 Rust 特有的設計模式。我想讀到更多關於 Rust 在業界實際應用的內容，看到來自不同產業的案例研究。舉例來說，有一家叫做 snips.ai 的新創公司，用 Rust 打造了裝置端的語音助理。他們整合了 C 和 C++ 函式庫，而我很想多聽聽他們一路走來的經驗。

改進 RFC 流程

我盡量緊跟 RFC 的流程，但時間有限。我的願望是，隨便打開一份 RFC，就能立刻掌握它的現況：

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

舉例來說，如果我點開這個（看似隨機的）議題，我甚至不知道該從何看起。目前最大的阻礙是什麼？是誰正在積極推動？而我又能怎麼幫忙？

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

老面孔

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

當然還有更多可以提的，但我就不拿更快的編譯速度、impl Trait、generators 之類的東西來煩你了。我們已經走在正確的方向上了，詳情可以看看Nick Cameron 的文章。

我相信，只要改善文件和指導制度，我們就能大幅增加貢獻者的人數，並在今年穩定許多備受期待的功能。

^{1. 免責聲明：我從來沒看過任何一集《金剛戰士》。↩}