一些關於Rust在2019年的思考

每一年,咱們都會要求社區撰寫有關他們但願在Rust的明年路線圖中看到的內容的博客文章。 A call for Rust 2019 Roadmap blog posts這是我在2019年的Rust帖子。html

Rust 2021: 成熟

今年也有點特別; 在2018年,咱們對Rust推出了大約三年的版本時間表。 因此如今不只是思考2019年的好時機,並且也是2020年和2021年的時候。 Rust在2015年的一些思考是關於「穩定性」的。 Rust在2018年的一些思考是關於「生產力」的。我但願Rust在2021年的一些思考可以是關於「成熟」的。git

爲了實現這一目標,這是咱們在2019年所須要的。程序員

No new features(新特性,但不是新事物)

Emphasis on 「new」 here. What do I mean by this? Well, there are a few features that are in the pipeline that I do think should land:
這裏強調「新」。 這是什麼意思? 好吧,我認爲應該落地一些關於 pipeline 的功能:編程

async/await
GATs
const generics

And possibly(可能的特性)

Specialization

這些功能都不是新的; 咱們已經有了他們的基本設計。 這些特徵也具備重要意義和基礎性; 咱們須要 sync/await(或者GATs)來創建一個偉大的網絡編程體系,咱們須要const、泛型來得到一個優秀的數值系統。網絡

但那以後呢? 若是能夠的話,我更願意咱們受限在2020年或某一年,在這以前暫停主要功能,async

咱們已經到了一個甜蜜期。 咱們老是說Rust 1.0是穩定的而不是完整的。 我想咱們正在快速接近完整。gitlab

也就是說,我不認爲語言團隊應該解散; 我認爲他們的工做應該過渡到詳細說明咱們已有的東西。 我不肯定咱們是否能夠在2019年完成 reference 的編寫(稍後會詳細介紹),但我但願它可以更進一步。 這隻能在語言團隊的幫助下進行,他們只有在有時間的狀況下才能進行這項工做。post

優化RFC(Request For Comments徵求修正意見書)流程

RFC流程須要從新進行設計。 Niko在6月份寫了一篇很棒的帖子,我認爲這真的很是很是重要。 我想在RFC上提出這個建議,因此若是你有興趣,咱們應該談談。優化

Niko已經提出了案例,並提出了一些基礎,因此我不會說更多。this

減小團隊債務

考慮到我對withoutboats博客的文章《Organizational Debt》所說的全部內容的承認。 我不能說得比它更好,因此我會把它留在這。

解決文檔的可持續性問題

今年對於文檔團隊來講是糟糕的一年。 這本書出貨了,這很棒。 咱們有一些人蔘與 reference的編寫,他們的工做是驚人的。 一些其餘文檔編寫者繼續研究rustdoc,這很重要。

可是,咱們想要作編寫更多文檔的目標從未實現過。 例如,從未沒有爲主要的生態系統 crates 作出貢獻、手冊沒有完成、 Rust by Example仍然精神萎頓。 標準庫還不夠友好。

咱們只是沒有讓人們作到這一點。 咱們已經嘗試過,但沒有任何效果。 這多是根本沒法修復的,畢竟大多數程序員都不喜歡編寫文檔。 但我也不想放棄它。 我不知道該怎麼作,但我知道這是一個主要問題。

總而言之

還有不少工做要作,我很高興能作到這份工做。 我認爲Rust是一個很好的東西,經過一些工做,咱們可讓Rust在一年的時間裏變得更加使人振奮。

相關文章
相關標籤/搜索