2017-01-10 更新：修復壞掉的超鏈接，修正 "This sort is stable" 的翻譯

———— 分割線 —————-

本文翻譯自 Steve Klabnik 的博客。Steve 是 Rust 核心團隊成員，主要負責文檔撰寫和社區(qū)建設。這篇文章是 Rust 0.5 發(fā)布公告的一個考古文，對比著今天的 Rust 看還是蠻有意思的

———— 分割線 —————-

從我第一次聽說 Rust 語言到今天已經(jīng)是第 4 個年頭了。之所以還記得這個日子是因為我用的第一個 Rust 版本是 0.5。這四年來 Rust 發(fā)生了很大的變化。關于發(fā)展歷史概況可以觀看我這個演講。但是我覺得今天回過頭來去查查當時的發(fā)布公告，看看哪些東西發(fā)生了變化，哪些東西仍然保留會很有意思。

rust-dev

首先說說公告本身，rust-dev 郵件列表曾經(jīng)是 Rust 存檔形式的一站式討論聚焦地。不過在 2015年1月，我們決定關掉它。為什么呢？讓我們回顧一下 Brian 當時說的你很可能已經(jīng)注意到了，最近幾個月 rust-dev 郵件列表流量大幅下降。這最初是項目協(xié)調(diào)的自然結果，繼而我們又刻意逐步廢掉郵件列表。

項目最初用來討論 Rust 的只有 #rust 頻道和 rust-dev 郵件列表兩個地方，并且多年來我們一直很開心地用這兩種交流方式。隨著項目的發(fā)展，項目協(xié)調(diào)也被轉移到不同渠道，大家在許多不同的地方交流，于是 rust-dev 郵件列表的目的變得不那么明確了。與此同時郵件列表里面也出現(xiàn)了許多白熱化不受管理的撕逼討論，導致許多人對郵件列表的有效性失去了信心。

我喜歡郵件列表，但我知道在這方面我比較獨特。但郵件列表的確有一個很大的問題，管理員的管理功能很弱。你當然可以禁言某人，但這就是你所能做的全部管理了。不能只刪除某些帖子，不能設置冷靜時段，不能 shadow banning(譯注：被禁言者依然可以發(fā)言，不過其他人看不到)。盡管 Rust 社區(qū)在管理上面廣受贊譽，但絕不代表一切都很完美。我們艱難地從經(jīng)驗中吸取教訓。

并且 mailman 在某種意義上是開源界的“老土貨”，大家把它看作落后過時的東西。現(xiàn)在很少有人想用郵件，文化在發(fā)生變化，我們意識到這一點，所以決定轉向 Discourse。rust-dev 以 Discourse 的 users 和 internals 形式幸存下來。這兩個版塊的明顯區(qū)別是，前者討論 Rust，后者討論構建 Rust。Discourse 也同樣是自由/開源軟件，但是卻有更好的管理工具，甚至你仍然可以讓它給你發(fā)郵件。

我們也不會在這些論壇里做版本發(fā)布公告，我們有專門的博客發(fā)公告。

讓我們來818那次的發(fā)布注記！

900 個變更，大量的 bug 修復

900 個變更相當多！那時 Rust 基本上是6個月的發(fā)布周期，所以意味著每天有 5 個 PR 被合并。Rust 1.14 在6周的發(fā)布周期里會有 1230 個 PR，即每天有超過 29 個 PR。這是非常非常快的發(fā)展速度。而且這只算了我們的主倉庫，我們已經(jīng)加了更多的倉庫，比如 Cargo 和 crates.io。實際上這也是我很長一段時間以來的困擾，我們只在發(fā)布公告里表揚了給 rust-lang/rust 貢獻過代碼的人，基于這段歷史，現(xiàn)今發(fā)生了更多的事情。我想給 Rust 項目做一份像 Rails 貢獻者一樣的列表，誰愿意抽時間跟我一起來做這個工作？

語法變化刪掉 move 操作符

Rust 在生命周期”什么時候 move ，什么時候 copy ”的語法表示上經(jīng)歷過好多次迭代。如今是通過看類型是否實現(xiàn)了 Copy 來做區(qū)分的。但是過去 Rust 有多種形式，我用的第一個版本的 Rust 移除了這個語法，盡管我記得不大清楚，但我想應該是下面這樣的

x

x = y; // copy

我相信 Rust 還曾用過下面這種形式

x = move y; // move

x = y; // copy

我們決定在語法上統(tǒng)一這兩種形式的兩個理由是：第一，標注看起來是比較繁重的活，如果你弄錯了，編譯器會告訴你應該用 move 還是 copy。第二，至少在如今的 Rust 里 move 和 copy 是等價的操作，除了在這兩個操作之后，你能否繼續(xù)用舊變量這一點區(qū)別之外。而讓 move 和 copy 操作使用相同的語法則強化了這一點。

Niko 的博客里有很多很贊的歷史細節(jié)，關于這個話題也不例外完成了從 #fmt 擴展語法到 fmt! 的徹底轉換

很久以前 Rust 有一條規(guī)則 “關鍵字不能超過 5 個字母”，所以很多詞都被簡寫了。這個特殊的語法擴展延續(xù)到今天，只不過換成了更長的名字 format!移除了原來固定長度向量的語法 - [T]/N

我們今天所知道的 Rust 里面的向量和數(shù)組類型經(jīng)歷過很多內(nèi)部迭代。[T]/N 在今天的等價形式是 [T; N]，但是我敢肯定的是這兩種表示方式也有些細微的差別，不過我不大記得了。quasi-quoter 的新語法 quote_tokens!, quote_expr! 等

這些在某種意義上仍然存在，不過始終沒有穩(wěn)定下來，以至于根本沒有出現(xiàn)在官方文檔里面，不過 Manish 維護著一份文檔拷貝。這些是“語法擴展”的工具，屬于 Rust 元編程最強有力的形式。它們的設計終稿8天前才被接收，所以等到在穩(wěn)定版 Rust 見到這個語法還要等好一陣子。宏現(xiàn)在可以延拓到 item 和 statement 了

盡管我不知道為什么之前宏不能這樣做，但是現(xiàn)在卻是可以的，而且也非常有用。a.b() 總是被解析成方法調(diào)用而不是一個字段

這是一個有意思的邊界情況，下面這段代碼展示了這一問題：

struct Env {

f: F,

}

let e = Env { f: |i| println!("Hello, {}", i) };

e.f(); // what does this do?

根據(jù)這一條注記，這里會是一個方法調(diào)用。但是如今卻會是一個錯誤，你需要寫成 (e.f)(); 才行，不過至少錯誤提示可以告訴你該怎么做

error: no method named `f` found for type `Env:6:22: 6:50]>` in the current scope

--> :8:7

|

8 | e.f(); // what does this do?

| ^

|

note: use `(e.f)(...)` if you meant to call the function stored in the `f` field

--> :8:7

|

8 | e.f(); // what does this do?

| ^通過 #[deriving_eq] 和 #[deriving_iter_bytes] 會自動生成 Eq 和 IterBytes 的實現(xiàn)

我們現(xiàn)在有更通用的方法派生 trait：例如 #[derive(Eq)]。Eq trait 現(xiàn)在仍然存在，而 IterBytes trait 則已經(jīng)不存在了，我不大記得這個 trait 是干啥的了。

當前哪些 trait 可以派生仍然只能由編譯器決定的，對于一些像 Serde 和 Diesel 這樣實用的庫，這也成了大家用 nightly 版本的一個重要原因。但是隨著 1.15 版本的到來，這一限制將會放寬，大家使用穩(wěn)定版 Rust 的一個最大障礙將會被消除！???移除了 .rc 文件的特殊 crate 語言(譯注：應該是之前 crate 文件需要手動用 DSL 來描述)

今天與 .rc 文件等價的是 .crate 文件，這些文件會被 Cargo 上傳到 http://crates.io。但是與 0.5 時代不同的是，現(xiàn)在你幾乎從來不用關心這些，因為 Cargo 使之能工作。函數(shù)參數(shù)可以由 irrefutable 模式構成

的確如此，而且也是大家所知道的一個事實！像下面這樣的：

struct Point {

x: i32,

y: i32,

}

fn takes_point(Point {x, y}: Point) {

println!("({}, {})", x, y);

}

fn main() {

let origin = Point { x: 0, y: 0 };

takes_point(origin);

}

即參數(shù)對于函數(shù)來說是 PATTERN: TYPE 而不是 NAME: TYPE，在上面的 takes_point 函數(shù)中作用域內(nèi)的是 x 和 y 而不是整個 point。

語義變化& 和 ~ 指針可以指向對象

Rust 很久以前的確是有對象的，不過我認為我接觸 Rust 時就已經(jīng)移除了，我不大清楚這一點。

值得一提的是 ~ 現(xiàn)在變成 Box 了，不過這又是一個很長的故事了。。。元組結構 - struct Foo(Bar, Baz) 替換了 newtype 枚舉Enum variant 可以是結構

現(xiàn)在也是如此

enum Foo {

Variant { x: i32, y: i32 },

}析構可以通過 Drop trait 加到所有標稱類型(nominal type)

現(xiàn)在也是如此

我覺得這里的 “nominal” 暗指 Rust 類型系統(tǒng)里面比較老的一些東西，如果沒記錯的話，現(xiàn)在 Rust 已經(jīng)不再區(qū)分這些了，所有類型都是 nominal 的，不過我不敢 100% 肯定。結構和空 enum variant 可以是常量

現(xiàn)在也是如此不能隱式拷貝的值不用顯式寫 move 也會被自動 move

我在上面談

現(xiàn)在 *T 可以是 *const T 或者是 *mut T，不過這條注記也是對的：

let x = &5;

let y: *const i32 = x;let 語句和函數(shù)調(diào)用里會發(fā)生強制類型轉換

多年來我們在“什么時候進行強制類型轉換什么時候不轉”上經(jīng)歷了許多不同的迭代。實際上我期望上面的例子中 *const i32 必需要有個 as 來做轉換。use 語句現(xiàn)在取的是 crate 相對路徑

現(xiàn)在也如此。我真的是很喜歡這一點，但是很多人發(fā)現(xiàn)這個很迷惑。基本上 “use” 總是從 crate 的根開始，所以有下面的

mod bar {

struct Foo;

mod baz {

use bar::Foo; // from the root

use super::Foo; // if you want to start from the parent

use self::super::Foo; // self makes it be relative. Not even sure if self + super works, but you get the idea.

}

}模塊和類型的名字空間合并了，以便靜態(tài)方法的名字可以在定義的 trait 里被查找到

這一條不太確定，也有點野生。

改善了語言特性的支持trait 繼承可以在許多場景下工作

用繼承這個詞一直有點不恰當，這里繼承是指

trait Foo: Bar {

}

如果你想實現(xiàn) Foo 的話，你必須還得實現(xiàn) Bar，就是這么回事。這一行讓我感到很愉快：“這個解釋比繼承更好”支持方法里顯式的帶上 self 參數(shù) - self, &self, @self 和 ~self 這些都如預期的一樣工作

現(xiàn)在的 Rust 不僅僅支持這么做，而且是強制要求帶上的，不過self 仍然是 self

&self 也仍然是 &self

@self 類似于 Rc

~self 則變成 Box

@self 本來是用來表示 GC 類型的，但卻除了用來引用計數(shù)外從來沒有成為 GC 類型

另外后面兩種也不是那樣寫的，而是 self: Rc 和 self: Box。 后者可以編譯，而 Rc 那個卻不行，因為 Box 有黑魔法。不過這一點最終會被修正過來。靜態(tài)方法可以在更多的情景下工作

又一行“哇，更多的特性可以工作”。：)實驗特性：Trait 可以定義默認的方法給 impl 用

如今也是，而且這一點很有用。考慮 Iterator：所有的方法都有默認實現(xiàn)，所以你只需要定義 next()，其它的方法就可以自動獲得了

庫core::condition 中新的 condition 處理系統(tǒng)

condition 是 Lisp 用來處理錯誤的方式，Rust 曾經(jīng)支持過一段時間。這一點非常酷，但是沒人知道如何有效的使用，所以也就沒有人去用，于是乎現(xiàn)在就消失了Timsort 被加到 std::sort

std::sort 現(xiàn)在已經(jīng)不存在了，盡管我們有 slice 排序函數(shù)。我們不再聲明是某種特別的算法，而只是說“這種排序方法是穩(wěn)定的，并且在最壞情況下是 O(n log n)，但是需要分配大約 2*n 的空間，其中 n 是 self 的長度”。

最近這個算法得到大量的改善，這些工作還是一個初次貢獻者做的，簡直干得太漂亮了。在這個 PR 里，他是這樣解釋這個算法的：然而如果我們從 TimSort(排序時智能歸并策略)中汲取主要觀點并且放棄 gallop，則對于隨機輸入可以獲得極高的性能，而且對于部分排序的輸入也不會太差。

TimSort 仍然在那并發(fā)揮著巨大的作用。新的優(yōu)先級隊列：std::priority_queue針對可序列化類型的管道： std::flatpipes

不知道如今這個東西去哪里了序列化大幅修改變成基于 trait 的了

如今也是。見上面提到的 Serde，不過 rustc-serialize 算是作弊，編譯器可以理解 RustcEncodable 和 RustcDecodable。對于 1.15 的到來迫不及待！擴展了 getopts 定義將 futures 移到 std

臥靠！我都忘了我們曾經(jīng)在標準庫里是有 futures 的。Futures 是現(xiàn)在 Rust 社區(qū)里最火的話題之一。Tokio是 Rust 圈里有史以來最受期待的發(fā)布之一。想嘗鮮的可以看看這個演講。一個哥們告訴我 Tokio 很快就會發(fā)布 0.1 了。。。有更多的純函數(shù)了

Rust 已經(jīng)沒有純函數(shù)的概念了，盡管 const fn(仍然是 unstable)在某種程度上算是純函數(shù)。關于 Rust 純函數(shù)的歷史可以看看 Niko 的博客，或者是 Graydon 關于為什么純函數(shù)被移除了的解釋。core::comm 重命名為 oldcomm，仍然是廢棄的

很早很早以前就消失了rustdoc 和 cargo 現(xiàn)在變成庫了

Rustdoc 仍然存在，不過不是以庫的形式。Cargo 則已經(jīng)不是你所想的 cargo 了，完全是另一個東西。在當前的 cargo 之前，Rust 的包管理經(jīng)歷過許多次迭代。例如曾經(jīng)有 rustpkg，出現(xiàn)在這里提到的 Cargo 之后，今天我們用的 Cargo 之前。

雜項初步增加了 REPL：rusti

我們現(xiàn)在從 Rust 源碼里移除了 repl，因為 repl 從來沒有真正起作用過，而且還是代碼維護的噩夢。這個是當前我所知道的唯一一個。一些人要求提供一個，不過沒有人一起來做這件事去實現(xiàn)一個好用的 repl。這是一件很艱難的事情！許可證從 MIT 變成了 MIT/APL2 雙許可證

現(xiàn)在也是如此，也沒有計劃改變這個。

Rust 0.5 的貢獻者：

Rust 0.5 版本有 41 個貢獻者，而 1.14 則有 144 個，這是這些日子以來的每版的平均貢獻者人數(shù)。這 41 個人中，我粗略看了下，認出了其中 17 個人的名字，其中大概有 6 個依然參與著當前 Rust 和 Servo 項目，另外 11 個人呢？一些是實習生現(xiàn)在已經(jīng)在其它地方工作了，所以不能繼續(xù)為 Rust 工作了，一些貢獻者由于不同的原因離開了，自然包括 Graydon。

在發(fā)現(xiàn) Rust 語言后第六天我提了我個人的第一個 PR。你會注意到這個 PR 沒有被合并，原因是操作失誤，我把它發(fā)到錯誤的分支上去了！現(xiàn)在 GitHub 允許你修改這樣的失誤，但是我當時又開了另一個 PR。

我在那個 PR 里面是這樣說的：我剛剛開始使用 Rust，并且非常喜歡它。其中一個讓 Rust 顯得很困難的是文檔的缺乏，當然這沒什么大問題，畢竟 Rust 還沒有達到生產(chǎn)可用。

我愿意幫助改變這一點。

作為開始，我只是修改了 rustdoc 里面這一段短短的描述，如果這個有幫助，并且你們都喜歡我的修改，我將會按這種方式修改 core 的其它部分文檔，繼而可能修改 stdlib 的文檔。

你也許會說的確起作用了，我現(xiàn)在是核心團隊的一員了。從那之后我已經(jīng)提交了 866 個 PR，第一個 PR 在 Rust 0.6 版本里，而 Rust 0.10 是唯一一個我沒有提 PR 的版本。而現(xiàn)在我負責寫 Rust 發(fā)布公告。

我希望你喜歡這一小段記憶航線。如今我依然喜歡 Rust 及其社區(qū)，這是給未來更多年的??

?

總結

以上是生活随笔為你收集整理的rust货轮什么时候出现_与 Rust 在一起的四年的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。