rust货轮什么时候出现_与 Rust 在一起的四年
2017-01-10 更新：修復壞掉的超鏈接，修正 "This sort is stable" 的翻譯
———— 分割線 —————-
本文翻譯自 Steve Klabnik 的博客。Steve 是 Rust 核心團隊成員，主要負責文檔撰寫和社區建設。這篇文章是 Rust 0.5 發布公告的一個考古文，對比著今天的 Rust 看還是蠻有意思的
———— 分割線 —————-
從我第一次聽說 Rust 語言到今天已經是第 4 個年頭了。之所以還記得這個日子是因為我用的第一個 Rust 版本是 0.5。這四年來 Rust 發生了很大的變化。關于發展歷史概況可以觀看我這個演講。但是我覺得今天回過頭來去查查當時的發布公告，看看哪些東西發生了變化，哪些東西仍然保留會很有意思。
rust-dev
首先說說公告本身，rust-dev 郵件列表曾經是 Rust 存檔形式的一站式討論聚焦地。不過在 2015年1月，我們決定關掉它。為什么呢？讓我們回顧一下 Brian 當時說的你很可能已經注意到了，最近幾個月 rust-dev 郵件列表流量大幅下降。這最初是項目協調的自然結果，繼而我們又刻意逐步廢掉郵件列表。
項目最初用來討論 Rust 的只有 #rust 頻道和 rust-dev 郵件列表兩個地方，并且多年來我們一直很開心地用這兩種交流方式。隨著項目的發展，項目協調也被轉移到不同渠道，大家在許多不同的地方交流，于是 rust-dev 郵件列表的目的變得不那么明確了。與此同時郵件列表里面也出現了許多白熱化不受管理的撕逼討論，導致許多人對郵件列表的有效性失去了信心。
我喜歡郵件列表，但我知道在這方面我比較獨特。但郵件列表的確有一個很大的問題，管理員的管理功能很弱。你當然可以禁言某人，但這就是你所能做的全部管理了。不能只刪除某些帖子，不能設置冷靜時段，不能 shadow banning(譯注：被禁言者依然可以發言，不過其他人看不到)。盡管 Rust 社區在管理上面廣受贊譽，但絕不代表一切都很完美。我們艱難地從經驗中吸取教訓。
并且 mailman 在某種意義上是開源界的“老土貨”，大家把它看作落后過時的東西。現在很少有人想用郵件，文化在發生變化，我們意識到這一點，所以決定轉向 Discourse。rust-dev 以 Discourse 的 users 和 internals 形式幸存下來。這兩個版塊的明顯區別是，前者討論 Rust，后者討論構建 Rust。Discourse 也同樣是自由/開源軟件，但是卻有更好的管理工具，甚至你仍然可以讓它給你發郵件。
我們也不會在這些論壇里做版本發布公告，我們有專門的博客發公告。
讓我們來818那次的發布注記！
900 個變更，大量的 bug 修復
900 個變更相當多！那時 Rust 基本上是6個月的發布周期，所以意味著每天有 5 個 PR 被合并。Rust 1.14 在6周的發布周期里會有 1230 個 PR，即每天有超過 29 個 PR。這是非常非常快的發展速度。而且這只算了我們的主倉庫，我們已經加了更多的倉庫，比如 Cargo 和 crates.io。實際上這也是我很長一段時間以來的困擾，我們只在發布公告里表揚了給 rust-lang/rust 貢獻過代碼的人，基于這段歷史，現今發生了更多的事情。我想給 Rust 項目做一份像 Rails 貢獻者一樣的列表，誰愿意抽時間跟我一起來做這個工作？
語法變化刪掉 move 操作符
Rust 在生命周期”什么時候 move ，什么時候 copy ”的語法表示上經歷過好多次迭代。如今是通過看類型是否實現了 Copy 來做區分的。但是過去 Rust 有多種形式，我用的第一個版本的 Rust 移除了這個語法，盡管我記得不大清楚，但我想應該是下面這樣的
x
x = y; // copy
我相信 Rust 還曾用過下面這種形式
x = move y; // move
x = y; // copy
我們決定在語法上統一這兩種形式的兩個理由是：第一，標注看起來是比較繁重的活，如果你弄錯了，編譯器會告訴你應該用 move 還是 copy。第二，至少在如今的 Rust 里 move 和 copy 是等價的操作，除了在這兩個操作之后，你能否繼續用舊變量這一點區別之外。而讓 move 和 copy 操作使用相同的語法則強化了這一點。
Niko 的博客里有很多很贊的歷史細節，關于這個話題也不例外完成了從 #fmt 擴展語法到 fmt! 的徹底轉換
很久以前 Rust 有一條規則 “關鍵字不能超過 5 個字母”，所以很多詞都被簡寫了。這個特殊的語法擴展延續到今天，只不過換成了更長的名字 format!移除了原來固定長度向量的語法 - [T]/N
我們今天所知道的 Rust 里面的向量和數組類型經歷過很多內部迭代。[T]/N 在今天的等價形式是 [T; N]，但是我敢肯定的是這兩種表示方式也有些細微的差別，不過我不大記得了。quasi-quoter 的新語法 quote_tokens!, quote_expr! 等
這些在某種意義上仍然存在，不過始終沒有穩定下來，以至于根本沒有出現在官方文檔里面，不過 Manish 維護著一份文檔拷貝。這些是“語法擴展”的工具，屬于 Rust 元編程最強有力的形式。它們的設計終稿8天前才被接收，所以等到在穩定版 Rust 見到這個語法還要等好一陣子。宏現在可以延拓到 item 和 statement 了
盡管我不知道為什么之前宏不能這樣做，但是現在卻是可以的，而且也非常有用。a.b() 總是被解析成方法調用而不是一個字段
這是一個有意思的邊界情況，下面這段代碼展示了這一問題：
struct Env {
f: F,
}
let e = Env { f: |i| println!("Hello, {}", i) };
e.f(); // what does this do?
根據這一條注記，這里會是一個方法調用。但是如今卻會是一個錯誤，你需要寫成 (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 的實現
我們現在有更通用的方法派生 trait：例如 #[derive(Eq)]。Eq trait 現在仍然存在，而 IterBytes trait 則已經不存在了，我不大記得這個 trait 是干啥的了。
當前哪些 trait 可以派生仍然只能由編譯器決定的，對于一些像 Serde 和 Diesel 這樣實用的庫，這也成了大家用 nightly 版本的一個重要原因。但是隨著 1.15 版本的到來，這一限制將會放寬，大家使用穩定版 Rust 的一個最大障礙將會被消除！???移除了 .rc 文件的特殊 crate 語言(譯注：應該是之前 crate 文件需要手動用 DSL 來描述)
今天與 .rc 文件等價的是 .crate 文件，這些文件會被 Cargo 上傳到 http://crates.io。但是與 0.5 時代不同的是，現在你幾乎從來不用關心這些，因為 Cargo 使之能工作。函數參數可以由 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);
}
即參數對于函數來說是 PATTERN: TYPE 而不是 NAME: TYPE，在上面的 takes_point 函數中作用域內的是 x 和 y 而不是整個 point。
語義變化& 和 ~ 指針可以指向對象
Rust 很久以前的確是有對象的，不過我認為我接觸 Rust 時就已經移除了，我不大清楚這一點。
值得一提的是 ~ 現在變成 Box 了，不過這又是一個很長的故事了。。。元組結構 - struct Foo(Bar, Baz) 替換了 newtype 枚舉Enum variant 可以是結構
現在也是如此
enum Foo {
Variant { x: i32, y: i32 },
}析構可以通過 Drop trait 加到所有標稱類型(nominal type)
現在也是如此
我覺得這里的 “nominal” 暗指 Rust 類型系統里面比較老的一些東西，如果沒記錯的話，現在 Rust 已經不再區分這些了，所有類型都是 nominal 的，不過我不敢 100% 肯定。結構和空 enum variant 可以是常量
現在也是如此不能隱式拷貝的值不用顯式寫 move 也會被自動 move
我在上面談
現在 *T 可以是 *const T 或者是 *mut T，不過這條注記也是對的：
let x = &5;
let y: *const i32 = x;let 語句和函數調用里會發生強制類型轉換
多年來我們在“什么時候進行強制類型轉換什么時候不轉”上經歷了許多不同的迭代。實際上我期望上面的例子中 *const i32 必需要有個 as 來做轉換。use 語句現在取的是 crate 相對路徑
現在也如此。我真的是很喜歡這一點，但是很多人發現這個很迷惑。基本上 “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.
}
}模塊和類型的名字空間合并了，以便靜態方法的名字可以在定義的 trait 里被查找到
這一條不太確定，也有點野生。
改善了語言特性的支持trait 繼承可以在許多場景下工作
用繼承這個詞一直有點不恰當，這里繼承是指
trait Foo: Bar {
}
如果你想實現 Foo 的話，你必須還得實現 Bar，就是這么回事。這一行讓我感到很愉快：“這個解釋比繼承更好”支持方法里顯式的帶上 self 參數 - self, &self, @self 和 ~self 這些都如預期的一樣工作
現在的 Rust 不僅僅支持這么做，而且是強制要求帶上的，不過self 仍然是 self
&self 也仍然是 &self
@self 類似于 Rc
~self 則變成 Box
@self 本來是用來表示 GC 類型的，但卻除了用來引用計數外從來沒有成為 GC 類型
另外后面兩種也不是那樣寫的，而是 self: Rc 和 self: Box。 后者可以編譯，而 Rc 那個卻不行，因為 Box 有黑魔法。不過這一點最終會被修正過來。靜態方法可以在更多的情景下工作
又一行“哇，更多的特性可以工作”。：)實驗特性：Trait 可以定義默認的方法給 impl 用
如今也是，而且這一點很有用。考慮 Iterator：所有的方法都有默認實現，所以你只需要定義 next()，其它的方法就可以自動獲得了
庫core::condition 中新的 condition 處理系統
condition 是 Lisp 用來處理錯誤的方式，Rust 曾經支持過一段時間。這一點非常酷，但是沒人知道如何有效的使用，所以也就沒有人去用，于是乎現在就消失了Timsort 被加到 std::sort
std::sort 現在已經不存在了，盡管我們有 slice 排序函數。我們不再聲明是某種特別的算法，而只是說“這種排序方法是穩定的，并且在最壞情況下是 O(n log n)，但是需要分配大約 2*n 的空間，其中 n 是 self 的長度”。
最近這個算法得到大量的改善，這些工作還是一個初次貢獻者做的，簡直干得太漂亮了。在這個 PR 里，他是這樣解釋這個算法的：然而如果我們從 TimSort(排序時智能歸并策略)中汲取主要觀點并且放棄 gallop，則對于隨機輸入可以獲得極高的性能，而且對于部分排序的輸入也不會太差。
TimSort 仍然在那并發揮著巨大的作用。新的優先級隊列：std::priority_queue針對可序列化類型的管道： std::flatpipes
不知道如今這個東西去哪里了序列化大幅修改變成基于 trait 的了
如今也是。見上面提到的 Serde，不過 rustc-serialize 算是作弊，編譯器可以理解 RustcEncodable 和 RustcDecodable。對于 1.15 的到來迫不及待！擴展了 getopts 定義將 futures 移到 std
臥靠！我都忘了我們曾經在標準庫里是有 futures 的。Futures 是現在 Rust 社區里最火的話題之一。Tokio是 Rust 圈里有史以來最受期待的發布之一。想嘗鮮的可以看看這個演講。一個哥們告訴我 Tokio 很快就會發布 0.1 了。。。有更多的純函數了
Rust 已經沒有純函數的概念了，盡管 const fn(仍然是 unstable)在某種程度上算是純函數。關于 Rust 純函數的歷史可以看看 Niko 的博客，或者是 Graydon 關于為什么純函數被移除了的解釋。core::comm 重命名為 oldcomm，仍然是廢棄的
很早很早以前就消失了rustdoc 和 cargo 現在變成庫了
Rustdoc 仍然存在，不過不是以庫的形式。Cargo 則已經不是你所想的 cargo 了，完全是另一個東西。在當前的 cargo 之前，Rust 的包管理經歷過許多次迭代。例如曾經有 rustpkg，出現在這里提到的 Cargo 之后，今天我們用的 Cargo 之前。
雜項初步增加了 REPL：rusti
我們現在從 Rust 源碼里移除了 repl，因為 repl 從來沒有真正起作用過，而且還是代碼維護的噩夢。這個是當前我所知道的唯一一個。一些人要求提供一個，不過沒有人一起來做這件事去實現一個好用的 repl。這是一件很艱難的事情！許可證從 MIT 變成了 MIT/APL2 雙許可證
現在也是如此，也沒有計劃改變這個。
Rust 0.5 的貢獻者：
Rust 0.5 版本有 41 個貢獻者，而 1.14 則有 144 個，這是這些日子以來的每版的平均貢獻者人數。這 41 個人中，我粗略看了下，認出了其中 17 個人的名字，其中大概有 6 個依然參與著當前 Rust 和 Servo 項目，另外 11 個人呢？一些是實習生現在已經在其它地方工作了，所以不能繼續為 Rust 工作了，一些貢獻者由于不同的原因離開了，自然包括 Graydon。
在發現 Rust 語言后第六天我提了我個人的第一個 PR。你會注意到這個 PR 沒有被合并，原因是操作失誤，我把它發到錯誤的分支上去了！現在 GitHub 允許你修改這樣的失誤，但是我當時又開了另一個 PR。
我在那個 PR 里面是這樣說的：我剛剛開始使用 Rust，并且非常喜歡它。其中一個讓 Rust 顯得很困難的是文檔的缺乏，當然這沒什么大問題，畢竟 Rust 還沒有達到生產可用。
我愿意幫助改變這一點。
作為開始，我只是修改了 rustdoc 里面這一段短短的描述，如果這個有幫助，并且你們都喜歡我的修改，我將會按這種方式修改 core 的其它部分文檔，繼而可能修改 stdlib 的文檔。
你也許會說的確起作用了，我現在是核心團隊的一員了。從那之后我已經提交了 866 個 PR，第一個 PR 在 Rust 0.6 版本里，而 Rust 0.10 是唯一一個我沒有提 PR 的版本。而現在我負責寫 Rust 發布公告。
我希望你喜歡這一小段記憶航線。如今我依然喜歡 Rust 及其社區，這是給未來更多年的??
?
總結
以上是生活随笔為你收集整理的rust货轮什么时候出现_与 Rust 在一起的四年的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python中 和is的区别_关于pyt
- 下一篇： python把桢写入txt_ffmpeg