在生产环境中使用Rust
Rust官方网站专门有一个页面，Friends of Rust（2016年4月底上线，持续更新），列出了在生产环境中使用Rust语言的组织和项目。
其中MaidSafe是有野心的项目，这一年来一直持续开发。Servo也是；而且会有越来越多的Rust开发的Servo组件迁入Firefox浏览器。
其他潜力股项目
· https://github.com/kbknapp/clap-rs
· https://github.com/sebcrozet/ncollide
· https://github.com/google/xi-editor
· https://github.com/nikomatsakis/lalrpop
I would like to nominate lalrpop. It's an LR(1) parser generator, where the syntax is written using a nice, quite Rust like language, and it's compiled into Rust code as a part of the build process. There's also the option to use your own token type and tokenizer, which is very nice for more advanced projects. (ogeon)
· https://github.com/tailhook/vagga
· https://github.com/das-labor/panopticon
· https://github.com/aturon/crossbeam
Libraries like crossbeam are probably more appropriate for the std. Lock-free containers(data structures). (LilianMoraru)
· https://github.com/nikomatsakis/rayon
Ok, if only 1 crate, I nominate rayon.
This crate is so good that I think that most applications should have a dependency on it.
Very easy to plug some concurrency into your application, and that it does very well. (LilianMoraru)
· https://github.com/carllerche/eventual
I would like to nominate eventual. It's a library that provides Future and Stream like abstractions and has a very easy to use interface. (maximih)
注：xi-editor项目虽然挂在Google名下，却不是Google公司官方项目；hat-backup项目的情况也类似。说明Google公司至少有两位作者在持续或深度使用Rust语言。以后在Google公司内部安利Rust就靠这哥俩了……
重量级PR（Pull Request）
· Regex #164: Add a lazy DFA （性能颇具竞争力）
· Url #176: Version 1.0, rewrite the data structure and API
· Hyper #778: Async IO
· Mio #239: Preliminary Windows TCP/UDP support
· Redox #552: Big IO change
· Rust #32756: Overhaul borrowck error messages and compiler error formatting generally
· Gtk-rs #221: Object reform
Rust社区生态系统升级
Crates.io中心仓库持续发展
crates.io 下载量 Top 10
· libc 共190万次下载
· winapi 共120万次下载
· rustc-serialize 共109万次下载
· rand 共101万次下载
· winapi-build 共99万次下载
· bitflags 共98万次下载
· log 共86万次下载
· kernel32-sys 共80万次下载
· gcc 共72万次下载
· time 共68万次下载
说明它们处于依赖链的顶层或接近顶层，大量项目直接或间接地依赖之。任意项目每次全新的编译都可能增加其下载次数，自动化的集成测试也贡献了许多下载量。
通过Cargo和crates.io网站把大大小小的第三方库聚合在一起，形成健康的生态系统，让项目依赖管理变得对开发者透明。
线上线下同性交友网络蓬勃发展
Github号称全球最大的线上同性交友网，名副其实。单单一个Rust仓库，就汇集了5.3万commits,1.7万issues,1.6万PRs,1.6万stars,3千forks,1千contributors。还有RFCs仓库几百个精华的设计文档和精彩的讨论细节。
大概从2015年8月起，在reddit.com/r/rust论坛上，每周都会发布两个置顶的新帖：
· “兄弟们这周都忙啥了？”（"What's everyone working on this week? "）后面的回复中网友纷纷踊跃发言说自己本周在用Rust写什么代码或做什么项目。
· “哥们有事您说话！”（"Hey Rustaceans! Got an easy question? Ask here! "）下面的回复有问有答，提出并解决各个技术问题。
这情景很和谐。真的就像一帮有情有义的光棍汉哥们围着电脑坐在一起认真的闲聊，聊工作，聊技术。虽然彼此之间隔着网络，心却是在一起的，相互有信任感和亲近感。
他们不把自己喜爱的语言当神供着，该吐槽的时候比谁都积极。在诸如 "Rust哪些地方最垃圾" "为何不在工作中使用Rust" 这类问题下面你会看到几百条回复。
线上火热，线下也不闲着。2016年1月份，全球Rust开发者共举办了13次有据可查的同性聚会；2月份15次；3月14次，4月份14次；5月份（刚过半）16次。活该没有女朋友，哼！ （此数据为粗略统计，截止到2016年5月中旬。）
以上数据部分来自 https://github.com/rust-lang/rust和https://this-week-in-rust.org/。
Rust价值观输出升级
以下列举的情况，有些可以证实是Rust输出了价值观，有些则不能证实。然而即使不能证实，至少也说明对方持有和Rust相类似的价值观，这也是我们喜闻乐见的。
简短的类型名称被WebAssembly采纳
由Mozilla, Microsoft, Google等几大浏览器巨头联合发起的WebAssembly项目（JS垄断地位的终结者），其value types从2015年9月开始直接使用跟Rust基本类型完全一致的命名：i32, i64, f32, f64。但变更记录并未提及是否借鉴于Rust。此前他们的value types命名曾几经变更。或许只是一个巧合也未可知。
另外，WebAssembly的block也是有值的，block的值就是block内最后一条expression的值。同样跟Rust不谋而合。
动力火车版本发布机制被Github Atom和Ethcore Parity采纳
Rust的Release channels机制原本是借鉴于Chrome，进而又影响了Github Atom和Ethcore Parity项目。Atom和Parity均声明受Rust影响而采用此发布机制。
这一机制可以表述为三列火车（nightly, beta, stable）在各自轨道上并驾齐驱。nightly火车，每天都往上装货（commit code），内容是最新的，但是可能不太稳定；beta火车，每隔6周从nightly火车上卸下一部分经过时间沉淀的货物装到自己车上（merge code），内容比较新，稳定性比较好；stable火车，每隔6周从beta火车上卸下一部分经过时间沉淀的货物，经过列车长人工过滤，确认检验无误之后装到自己车上，测试时间最长，测试最完整，稳定性最好，内容相对滞后。一个新特性从提交代码进入仓库到进入Stable版本，至少要经历nightly->beta、beta->stable两个周期，约3个月时间，才能跟最终用户相见；期间经历各种测试，一旦发现问题就会延迟进入Stable版本。但无论如何，最终用户总会每6周得到一次Stable版本升级。
Atom提供的这幅图十分形象的揭示了这一机制工作原理。（见图3）
图3
这种机制的好处是，在保证产品稳定性的前提下提供较频繁且平滑的升级体验。让用户没有心理负担地升级，乐于使用最新稳定版本，而不是像Java那样总想着憋N年搞一个大新闻出来，反而让某些用户有升级恐惧症。喜欢尝鲜的Rust用户，可以选用每日更新的nightly版本（或beta版本）。两边都不耽误。
RFCs
Rust早在2014年就开始逐步实施RFC机制。要求对代码做出重大改动或提议增加重要特性之前，发起者需要首先写出设计文档（即所谓“请求讨论稿” - Request For Comments），经过公开讨论逐步修正完善，并得到核心专家组批准之后，才能进入下一步编写代码实现功能阶段，最后还有一个标准化步骤，直至进入正式发行版(stable)。
这一机制的好处是：
· 强调设计在编码之前
· 强调公开的设计、公开的讨论、广泛地征求意见
· 强调核心专家组对设计方向和质量的把控
· 有利于积累专业的技术设计文档
· 避免某些模块的设计仅有个别人理解
· 提高代码的可审查性和可维护性
· 保证项目的高质量和发展方向
· 配合Feature-gate确保实验性项目在实验期间不流出实验室
这对开源软件的健康发展是至关重要的。别的项目也开始认可这一点，并参考实施，例如：
· https://github.com/emberjs/rfcs
· https://github.com/maidsafe/rfcs
· https://github.com/intermezzOS/rfcs
· https://github.com/rebuild-lang/rfcs
· https://github.com/fsharp/FSharpLangDesign
注：目前不能证实微软F#项目的RFC机制源于Rust。运作机制虽有所不同，但设计在前、公开讨论、官方审核等核心内容是一致的；RFC文本结构相似度很高。多讲一句，说起来F#和Rust还是亲戚呢，语言设计层面都跟OCaml语言有很深的渊源，Rust最初版本的编译器还是用OCaml开发的（当然现在早就换成Rust开发了）。