Rust(blog)是一门强调安全、并发、高效的系统编程语言。其中四个关键词，系统编程、安全、并发、高效，是Rust语言的核心特征，也是区别于其他编程语言的首要因素。

除此之外，我再补充一些关键词，以便读者更直观地了解Rust：静态类型/编译式语言/静态编译/动态编译、泛型/函数式/面向对象、模式匹配/ADT、DST/Associated Types/闭包(Closures)、Static/Dynamic/Multiple-Dispatch、 没有虚拟机(VM)、没有垃圾收集器(GC)、没有运行时(Runtime)、没有空指针/野指针/内存越界/缓冲区溢出/段错误、没有数据竞争(Data Race)……

Rust语言具有特性丰富、设计优良、适用范围广等诸多优点。

我(Liigo)从2013年底开始正式关注Rust项目，……至今有一年半了。其中有赞有批，有争有闹，也有贡献源码。本文所写的是我这些日子以来的所看、所闻、所感。

判断一门新的编程语言“是否靠谱”，是主观性很大的课题。Rust语言今日才刚刚发布1.0版本，它的未来发展走向如何，谁也说不清楚，说到底都是猜测。但是直觉告诉我，如果人靠谱、团队靠谱、技术能力靠谱、态度靠谱、社区靠谱，这个项目在很大程度上就是靠谱的、值得期待的。

谨以此文，献给我长久期待的 Rust 1.0！

相当彻底的开源项目，开放、透明、友好，进度热火朝天，动作大刀阔斧。这是我第一次亲身参与并观察到的如此大规模的开源编程语言项目的开发过程。（之前也关注过Go语言项目，但其规模要小得多。）

“热火朝天”，用于形容其工程量大、进度快、成效显著。看看Rust的 Release Notes，常见这类字眼：

还有很多就不一一列出了。Rust自从2012年1月20日发布0.1版，到现在的1.0正式版，平均每隔三个月发布一版，每次升级改进都多达一两千项。 Rust是在GitHub/Git上在线开发的，开发者对源代码的每一项改动（commits）都被版本管理系统记录在案，有据可查。 大多数是实质性的功能升级，不存在靠修改标点、配置文件、拼写错误、或者每改三五行代码就提交的凑数行为（在此严重鄙视Atom编辑器、Kotlin语言）。 反而常见动不动就一次提交上千行 甚至上万 行 Rust 代码的情况，例子比比皆是，。。。

有一个网站叫 "This Week in Rust"，每周进展公告，专门介绍Rust语言最近一周的最新重大变动，可供大家参考。里面的内容虽然不全，但颇有代表性。这个网站几经变迁，但是自2013年6月上线时起，两年来，作者cmr坚持每周更新，几乎从未中断。

总之我（Liigo）说Rust的开发“热火朝天”，一点也不夸张。（我还要顺便鄙视Apple公司，发布某某OS新版的时候，动不动就说“新增1500项API”，哎，咱还就较真儿了，去查，算上所有Function、所有Type、Type内的所有Method、所有常量定义—— #define XX 123，你懂的 ——勉强够数！跟Rust的 "~1500 changes" 相比，天上人间。）

大家可以比照近十年在中国大陆和近两年在南中国海的大型基建项目的进展速度，体会Rust那种热火朝天的开发场面。处于这样的开发环境下，所有人都深受鼓舞，所有人都知道，一切都会越来越好，知道所有的欠缺和困难都是暂时的。行动永远比语言有说服力。

“大刀阔斧”，用于形容其开发行为豪迈、干脆，持续追求“更好的设计和实现”，无包袱、无迁就。 只要有了更好的设计（或实现），经过深入讨论和评估之后，果断替换掉旧的设计（或实现）。 不管这项改动有多复杂、多麻烦，也不理会因此形成的大量不兼容性，勇往直前的行动。 说去胳膊就去胳膊，说卸腿就卸腿，就是眼睛它也敢摘下来镶个火眼金睛再装回去。牵一发而动全身的事情，干了可不止一次。 例子有很多，最典型的是libgreen，之前Rust靠它一条腿走路，后来有了libnative，两条腿走路，再后来全都砍掉，最终做到没有运行时(Runtime)。 其他的例子还有std::io/os/path的大型重构(I/O OSPath Reform)，重新设计然后无缝替换回去（有rustc、servo为证），可谓自己给自己做了大型手术。 一个新兴的项目，在真正面世之前的开发过程中，如果不经历几次这类大的阵痛，很难说它最终是成熟的和久经考验的。 如果因为各种顾虑而迁就、保留旧的设计（或实现），很难说最终的产品是完善的和设计优良的。 如果面世之前都不肯改进，面世定型之后改进的可能性就更小了（束手缚脚），缺陷可能伴随终生，令所有的用户长期的纠结。 （这种大刀阔斧，与我(Liigo)当年在易语言公司参与研发EF语言时我所主张并践行的观点一致。有意推迟发布1.0也是为了给完善产品留足充裕的时间。）

需要强调的是，Rust开发者大刀阔斧的日子，只发生在Rust 1.0正式版发布之前。1.0之后，他们将老老实实的遵守 SemVer 2.0 规范，再也不会轻易做出破坏代码向后兼容性的行为。本文后面还会谈到这一点。

2006年，创始人Graydon Hoare启动了Rust编程语言项目，利于业余时间开发了三年，完成Rust语言的第一个可用版本。早期的Rust编译器 rustboot 是用OCaml语言开发的。这三年间发生的事情，我们现在知道的并不多。根据创始人对Rust的命名，可以一窥其设计初衷：

2009年，Rust项目被Graydon Hoare赠送给（英文原文"was presented to"）Mozilla公司，并得到持续活跃地开发支持。Mozilla创建了以Graydon为首的专业团队全职开发Rust，并且开放源代码。

2010年至2011年，Rust语言的编译器被用Rust语言重写，完成自举，采用LLVM作为编译后端——之前的Rust编译器是用OCaml语言编写的。

2012年1月发布0.1版，第一个面向公众的预览版本问世。从那时起，平均每3个月发布一个新版本，版本号每次只加0.1，改动的内容却往往天翻地覆。2012年到2015年这三年多的时间里，开发者持续不断的改进Rust语言、编译器和标准库，翻新重修，精益求精。不断地否定自己，不断地超越自己，一步一个里程碑。

2012年2月，也就是Rust 0.1刚刚发布不久， Servo项目被创建，用Rust语言开发下一代浏览器引擎，目的在于验证Rust语言开发大型实用项目的能力。

2012年到2015年这三年多时间，Rust和Servo互相扶持着茁壮成长起来了。Mozilla公司在Rust和Servo这两个不盈利的开源项目上付出的大量人力物力财力和时间成本，体现了他们全力打造下一代全新系统编程语言的决心和气魄。但是他们很少花费精力在大规模宣传和营销上，导致大部分公众/开发者几乎从没听过Rust语言，仅靠长期的口碑相传吸引了一批慧眼识金的忠实的开发者。

Rust不是富二代也不是官二代，它没有一个有钱或有权的爹。Mozilla公司，论资金规模和影响力，远远不及Google、Apple、Microsoft，勉强算是二流公司，但是它依然给予了Rust长期的坚定的支持。

历经近十年精心打造，Rust靠自身实力赢得未来。2015年5月16日，Rust正式发布1.0版本，破茧成蝶，吹响进入新时代的号角。

现今的软件系统开发，从底层到中层到上层，大致分为以下三个层次：

其中，（底层）系统底层开发，强调对底层硬件的控制；（中层）系统应用开发，对CPU和内存的占用十分敏感；（上层）普通应用开发，更倾向于方便快捷的开发效率。通常意义上所说的“系统编程”，往往是指中底层系统开发。

Liigo认为，Rust语言足以胜任这三个层次的软件开发。理由是：Rust是静态类型的编译式语言，基于LLVM生成高度优化的代码，再加上没有垃圾收集器(GC)等额外的运行时开销，执行效率非常高，对内存的利用十分灵活，因而胜任（中层）系统应用开发；Rust具有丰富的语言特性，便捷的项目编译和依赖管理，充分可用的跨平台的标准库，因而胜任（上层）普通应用开发；Rust支持raw pointer、unsafte block、C ffi、asm!、No runtime，因而胜任（底层）系统底层开发。Rust语言特别强调并保证的内存安全，对于三个层次尤其是中底层，是额外的突出的加分项。

上面的论述偏向于理论，可能不如实践有说服力。下面我们看看现实中Rust已经做到了什么程度（不是能做什么，而是做了什么，咱们靠事实说话）：

早在2013年我(Liigo)开始关注Rust之前，那时候Rust还有可选的GC，还有不算小的Runtime，还有笨重的标准库。即使在那种情况下，都有人不断地尝试用Rust做底层开发（参见前面的链接）。后来，Rust有了几个大的动作，令其更加胜任系统底层开发工作：

Rust是名副其实的系统编程语言，在这个领域，它不惧怕跟任何对手竞争。向下，Rust可取代C语言地位；居中，Rust可挑战C++市场，向上，Rust可向Java、Python分一杯羹。总之，Rust精准定位于中底层系统应用开发，上可攻下可守，适用范围相当广泛，具有全能型选手的潜质。开发者们学习Rust语言，不怕没有用武之地。

Rust在2010年至2011年完成自举，使用Rust语言开发出Rust编译器rustc， 取代了之前用OCaml语言开发的Rust编译器rustboot。Rust标准库，很早就是Rust语言写的。这意味着，早在四年前，Rust早期核心开发人员，就已经是全职的Rust程序员了，一天八小时，几乎完全使用Rust语言编程：用Rust开发标准库(和其他库)，用Rust调用标准库开发编译器，用编译器编译标准库和编译器。等到1.0发布时，他们已经是具有多年极其丰富的Rust开发经验的程序员，这期间他们积累的大量设计开发经验和教训，无疑不断地推进了Rust自身的迭代更新。

有人说：没有必要自举，不自举不代表它没有这个能力。这话说的没有太大毛病。但是我们考虑如下两点：

所以自举越早对编程语言自身发展完善越有利，最好是在自身定型之前尽早自举。

在编程语言自身定型之前尽早自举，这句话说起来容易，实施起来却非常困难。语言不完善，某些功能就可能暂时没法实现；语言不稳定，需要不断的修正和改进，用它写的编译器也需要相应的大量的维护更新甚至重写，是很大的工作负担。所以很多新的编程语言的作者，不愿意（尽早）自举，相应地也就永久失去了自举带来的好处。

我（Liigo）举两个反例：

而Rust语言，偏偏克服了诸多困难，提前4年完成自举，成为是最成功的案例之一，充分的享受了自举的好处，不断地在实践中完善了自身的设计。

没有深度的实践，就没有优秀的设计。除了自举，Rust还有其他的深度实践。

（作者Liigo注：本节以下有关代码行数的数据于2015年7月30日得到修正，详情另见《关于Servo项目中Rust代码行数的数据来源》一文。）

Servo是Mozilla公司另外一个独立开发组的项目，启动于2012年初，跟Rust并行开发。多年来，在Rust语言从幼年到少年逐步成长、长期剧烈变动的情况下，Servo居然还能保持正常开发进度，实属不易。Patrick Walton在Servo开发组和Rust开发组都是核心程序员，Servo组的Lars Bergstrom经常参加Rust组的每周会议，这保证了两部门的有效沟通。Rust组经常会优先协助解决Servo组遇到的问题，维持Servo开发任务正常推进。

对于Rust而言，Servo项目存在的最大意义就是，它实践并印证了Rust语言具有实际的大中型项目开发能力（而不仅仅停留在理论上），同时获得了珍贵的设计开发经验和教训，反过来进一步促进了Rust自身的发展。Rust语言和标准库逐步发展到今天，许多优秀的设计得以引进，许多有缺陷的设计得以改良，都要感谢Servo这类大型实践项目，在Rust 1.0之前就已经长期存在。试想，如果Rust定型之后才启动Servo项目，实践中发现语言的重大设计缺陷又能怎样，反正木已成舟，悔之晚矣。

Servo已经通过了 Acid2 标准测试；可以 并发渲染 Github/Reddit/CNN 这类大型静态网页，性能 明显高于 当前的Firefox浏览器的Gecko引擎；可以无缝替换基于Chrome的CEF 框架；已经实验性的应用在Firefox OS平台(b2s)。2015年将发布测试版浏览器。Servo有机会成为浏览器历史上里程碑式的产品。

时至今日，rustc负责编译全世界所有的Rust源代码，包括rustc+std的30万行和servo的25万行，以及crates.io网站上的2000多个第三方库，是名副其实的大型成功项目。

代码量相比前两者而言要小的多，所以我算它是半个成功案例。代码虽少，但实用性、流行度有过之而无不及。全世界大约99%的Rust项目采用Cargo编译。crates.io网站上有2000多个包，总下载量超150万次。Cargo最大幅度地简化了Rust项目的编译和依赖管理，可以说是目前开发Rust项目的必备工具。

Rust 1.0被开发者视为第一个稳定可靠的可用于生产环境的正式版本。也就是要承诺：现有的大部分语言特性和标准库API要稳定下来，以后不能轻易改变，非得要变得话也得保持向后兼容；功能上要基本全面，至少要满足基本的软件开发需求，不能有明显的欠缺；质量上要有可靠性保证，不能动不动就这里有问题那里有问题。此外，还要给语言将来的发展留足余地。官方博客Road to Rust 1.0 对于 1.0 有详细的阐述。

任何认真的新编程语言面临“何时发布1.0版”这个问题时都会感到纠结。发布的越早吧，初级产品没经过多少实际检验，用户量一上来用的人多了，很可能爆出基础设计缺陷，不得已大幅翻修，导致口碑不佳，然后无人问津，项目就算失败了；发布的越晚吧，影响力小用户量一直上不去，也得不到太多实际检验，始终达不到1.0的水平，可能就一直默默无闻下去了。Rust在1.0发布时机上把握的还算比较到位：诞生快十年，高速发展三五年，吸引了一大批用户，自身也经过的“两个半”大型项目的实际检验。要说早，肯定是不早了。Rust没有盲目的早早发布1.0（例如在2012年），是因为他们对1.0期待很高，他们对自己要求很高，他们心里有一杆秤。因为他们是认真的。

为了在2015年5月保质保量发布Rust 1.0，他们提前做了哪些工作？

在2014年3月之前，Rust开发组并没有十分规范的开发流程，基本过程是这样：修改代码，提交PR，Review，Merger。这样导致的问题是，没有形成设计文档，一旦遇到较大规模的代码改动，别人想理解他的设计思路，首先要读懂他的代码，这给方案评估、代码评审制造了困难，而且容易形成无人理解或难于维护的代码。

从2014年3月开始，Rust引入了规范化的RFC流程。规定，对语言重大改动之前，需先提交RFC文档，写明包括意图、详细设计、优缺点等在内的完整技术方案，供社区集体讨论，最后提交到Rust核心开发组每周的专题会议上评估审核，获得批准之后才进入实施阶段（代码实现）。规范化RFC的好处是，首先形成了完整的技术文档，利于集体讨论、评估（进而优化方案），利于方案实施、后期维护，而且利于核心开发组主导项目进展方向。RFC流程实施一年来，在Rust发展过程中发挥了极其深远的作用，先后通过了一大批十分重要的RFC，有力地推动了Rust语言的革新。

举一个例子，说明社区会主动监督开发流程的规范性和透明度：2014年8月，官方人员aturon居然想偷偷摸摸地把unwrap方法改名为assert， PR #16436: API conventions cleanup(80+)，被网友发现(120+) 后引起极大争议。争议的起因是他们工作透明度不够，事先公示(50+) 范围不足，未得到充分讨论。最终这一改动被迫撤消。

增补：1.0发布前后筹备创建了Sub Teams，整合了各细分领域的开发专家，负责所属领域的RFC设计、讨论、评估、决策，令过程更专业化。之前的Core Team，只有少数几位官方核心开发人员，地位相当于我党的政治局常委会，技术、能力、威望都很牛逼，但随着开发规模的扩大，他们自己也忙的团团转，疲于参与呈爆发式增长的RFC，工作效率不高，况且他们未必在所有细分领域都是专家，一把抓并不理想。组建Language Design Team, Library Team, Compiler Team, Tooling and Infrastructure Team, Community Team, Moderation Team 等 Sub Teams之后，各自吸纳了来自官方和民间的细分领域专家，可以更加专业化更有针对性的处理本领域的RFC，同时给Core Team节省出宝贵的精力去处理更核心的工作（Sub Teams有时上报某些重要RFC给Core Team决策）。参见RFC #1068。

增补：1.0发布后对每周技术例会(meetimg-minutes)做了较大调整。之前的惯例是，民间开发人员在RFC页面上讨论，然后Core Team开发人员在每周例会上讨论并决策，最后公布会议记录。之后的惯例是，民间和官方人员一起在RFC页面讨论，然后Sub team闭门决策（必要时Core Team介入），最后公布决策结果。调整之后，讨论更民主化、透明化，决策更集中化，提升了工作效率。

增补：（2014年那时候，北京时间每周三凌晨Core Team发布会议记录，每周三就是我(Liigo)的节日，早上起床看Core Team的技术讨论和决策过程，持续了大约一年，现在还是美好的回忆。后来Sub Teams的会议记录通常只剩下决策结果，没有技术讨论过程了，而且他们的发布间隔也延长到两周左右。）

增补：1.0发布后为RFC增设了 “Final Comment Period (FCP)” 窗口期，并及时公告，使得关注该RFC的开发者不会轻易错过决策前的最后集中讨论阶段。这也是提供开发透明度的一项措施。同样参见RFC #1068。

Steve Klabnik之前写过一篇介绍Rust的入门教程 Rust for Rubyists，文风娓娓道来，深得群众喜爱。2014年2月，Rust官方人员看重了他的文档写作才华，付费聘请 他全职为Rust创作文档。他的主要代表作是Rust官方的The Rust Programming Language(Rust Book)，以及大量API Docs。因为其卓越贡献，steveklabnik目前已经成为Rust核心开发组 八成员之一。

Tilde公司以前开发的Ruby包管理器Bundler在Ruby领域非常流行，其架构设计被实践证实获得成功。2014年3月，Rust官方 宣布 聘请 Tilde公司的核心技术人员Yehuda Katz和Carl Lerche，全职为Rust设计开发全新的开源的Cargo，目标是打造世界级的包管理器("a world-class package manager for Rust")。现在Cargo已经初步获得了很大的成功，还在蓬勃发展中。因为Yehuda Katz的卓越贡献，他已经成为Rust核心开发组 八成员之一。

深受好评的Rust学习示例网站 http://rustbyexample.com 的早期创建者 Jorge Aparicio(japaric) 后来被邀请加入 了（Mozilla公司的）Rust官方团队。

去 meeting-minutes 里面搜索 "Friend of the Tree" 或 "fott" 你会发现更多人陆续加入了Rust开发团队。

社区用Rust开发的或与Rust相关的开源项目进展地风风火火: Servo, Cargo, rust-by-example, Hyper, Piston, coreutils, rust-postgres, gfx-rs, conrod, rust-sdl2, rust-crypto, docopt.rs, zinc, gl-rs, racer, rust-bindgen, glfw-rs, capnproto-rust, rust-rosetta, graphics, rust-openssl, rust-encoding, hematite, capnproto-rust, glium, html5ever, glutin, rust-layers, rust-serde ……

我上面列出的多是长期以来持续开发和维护的项目，这在Rust语言长期剧烈变动的情况下愈显弥足珍贵。理智的人们不会无缘无故的花费大量时间和精力。许多忠实的第三方开发者长期地投资Rust项目，体现了他们对于Rust语言的热爱和对其前景的看好。