这周以来 Rust1.0 发布已经三个月了。随着开始向着下一个 1.0 版本迈进，我们很乐意地回顾 1.0 版本，并且讨论一下明年 Rust 的发展。 关于1.0版本Rust 1.0 专注于稳定性，社区性和明确性。
总之，Rust 是让人兴奋的，因为它是允许肆意发挥而没有任何担心，并且在你从来没接触过的环境下做这些。放下 Ruby 或是 python 这些语言，让你第一次进军系统编程。
这是 Rust 1.0，但是下一个版本将会带来什么？ 我们从这里走向哪儿
在和这些核心团队、早期的生产用户和广泛的社区的多次讨论之后，我们已经认识到了许多能提高的地方，并将在下一步做出一些修改，在以下三个方面：
让我们对这三个类别中庞大的计划拭目以待。 加倍下注: 基础设施投资
Crater对于 Rust，基础的稳定性承诺是能在版本间“轻而易举地”升级。为了兑现这个承诺，我们需要检测引发代码在编译中停止工作的 bug。自然地，编译器有它自己的大型测试套件，但是那仅仅是代码中的小片段，它就在那，“自然而然地存在在那”。Crater 是一个工具，目标是通过 crates.io 结束测试编译所有能找到的包，并让我们更加清楚地了解代码停止编译都是否是在最近发生的。 Crater 很快就变成为一个不可或缺的工具。我们经常比较最近的稳定版本和其他版本，并且我们使用crater 去检查进行中的分支和评估改变带来的影响。 有趣地是，我们常常发现代码停止编译的时候，不是因为在编译中存在 bug，而是因为我们修复了一个bug，代码对老的行为产生了依赖。在这种情况下，使用 crater 能帮助我们改进体验，它会建议我们在警告中逐步缓慢地修复。 在未来的一年，我们计划采用以下方式去改进 crater：
增量编译Rust 原本就有一个“crate-wide”编译模型。这意味着 Rust 编译器能一次性读取在你的 crate 中的所有源文件。先进行语法检查然后交由 LLVM 进行优化。这种方法对进行深度优化是有好处的，因为它能够让 LLVM 完全进入整个代码集，使得内联更强，分析更精确等等。然而这可能意味着这种转变很低：甚至只要你编辑了一个函数，我们都会重新对所有代码进行编译。当项目 变得庞大时，这就会造成负担。
增量编译的目标是，利用 Rust 编译器具备立即保存副产品并使用这些副产品的机制来改变这一不利的状况。用这种方法，当你在调试一个问题或者调整代码路径时，你只要重新编译你改变了的部分，这样将使得“编辑-编译-测试”循环要快得多。 这个工程的一部分在于重构这个编译器以介绍一个新的中间代表性编译器，我们称之为 MIR。MIR 是一个更为简单的和从 Rust 更为复杂特性的代码中凝练出的更底层的编译器，这使得这个编译器的剩余部分更加简单。这是语言改变的重要使能器，如同非词汇寿命期那样（下一部分会谈到）。 IDE整合
一流 IDE 的支持能使得 Rust 更加富有成效。直到现在开拓型的工程如 Racer，Visual Rust 和 Rust DT 都在没有编译器的支持下进行大部分的工作。我们计划延展这个编译器以请允许和 IDE 及其它工具更深层次的整合，这个计划起初关注两个 IDE，并从那里发展起来。 聚焦: 缩小主要功能的差距Specialization • 不会用到的，就不需要为其付出。 •需要用到的，务必做到最好。 Rust 1.0 基本上达到了第一个目标，包括语言功能和标准库两方面。但是还没有完全实现第二个目标。例如下面的trait:
Extend 这个trait很好的对任意类型的迭代器插入一个 collection 进行了抽象。不过对于目前的trait来说，这也意味着每个 collection 只能提供一种可以支持所有迭代器类型的实现，也就是循环的调用.next()。其实有时你可能会有更好的办法，例如只需要调用 memcpy。 为了弥补这个差距，我们提出了一个 specialization，允许你提供多重的，叠加的trait实现，只要一个比另一个更具体。除了为 Rust 提供更完备的零成本抽象化需要的工具之外，specialization 还包含了代码重用的改进。详情参考这个 the RFC。 Borrow checker 的改进 某种意义 上borrow checker 是 Rust 的核心；它是编译器的一部分，通过截获“访问已释放内存”或者类似的 bug，能够让我们在不用垃圾收集的情况下对内存进行安全 的存取。不过有些不是 bug 的情况，borrower checker 偶尔“截获”到，例如下面的例子：
上面的代码片段一点问题也没有，不过因为 map 变量是从 match 借用（borrow）的，当 insert 改变 map 的时候，目前的 borrow checker 会认为有问题。我们计划很快解决这个问题，办法是通过重构 borrow checker，在更细粒度的（无词法的）区间去检查代码 – 在迁移到之前提到的MIR之后，这一步也成为可能。 插件 如果你有兴趣使用 Nightly 的 channel，目前你可以为 Rust 做很多确实很优雅的事情 。例如，regex crate 提供的宏可以在编译时把正则表达式转换成对应的机器码。再如 rust-postgres-macros crate，可以在编译时检查 SQL 语句的语法。这些 crate 用到了一个编译器的插件系统，这个插件系统很不稳定，并且暴露出太多的编译器内部细节。我们计划提出一个新的插件系统的设计，这个插件系统会更稳定，并且内置了对安全的宏扩展的支持。 Rust 应用领域分支：把 Rust 带到新的领域。交叉编译：虽然目前的 Rust 能够支持交叉编译，但该过程需要大量的人工参与配置。我们已启动交叉编译按钮。编译 Rust 代码到另一目标应该是足够简单： 1：只需要下载一个目标对应版本的预编译 libstd 库 2：执行 cargo build --target=foo 3：没有第 3 步 Cargo installCargo 和 crates.io 已经是分发 Rust 库很棒的工具。但是它缺乏安装可执行文件的方法。 RFC120 0https://github.com/rust-lang/rfcs/pull/1200 描述了一个简单的选项支持 Cargo，就是 cargo install 命令。很像常规的 make install，cargo install 将安装执行路径到你的环境变量，使你能运行它。这可以作为一个简单的分发渠道，对于编写工具的 Rust 开发者（那些可能熟悉运行 cargo）是特别有用的。 跟踪挂钩 使用 Rust 的一个最为有前景的方法是把像 Ruby 或者 Python 那样的高级语言写成的 Rust 代码“嵌入”到系统中去。这一嵌入式通常是给予 Rust 代码一个 C 语言的 API 接口方式进行的，并且当其目标是运行一个“C友好型”的内存管理规划，像引用计数或者保守的 GC 那样，工作进来是相当合理的。 在使用更加先进的 GC 环境上进行整合可能相当具有挑战性。或许最突出的例子是像 V8 (使用 node.js)的 JavaScript 引擎和 SpiderMonkey (使用 Firefox 和 Servo)。整合这些引擎需要非常细心的代码以保证所有的目标都被正确地植入了；一点点的错误将导致崩溃。这正是 Rust 的几种内存管理的问题所将要予以排除的。 为了把 Rust 引入到更高级 GC 的环境中，Rust 团队计划扩展编译器的能力，使其能够产生追踪钩。这些钩子就可以被 GC 用来搜索堆栈和识别 root，大大简化与高级 VM 集成代码的编写工作。当然，设计将尊重锈病的“你用什么则支付什么”的政策，使得没有 GC 集成的代码不受影响。 结语：RustCamp（Rust 营地）2015 年和 2016 年的 Rust 社区我们最近召开了有 160人 参加的第一届 RustCamp 大会。看到如此多的 Rust 社区成员令人惊讶，从我们的火热线上空间氛围转化到友好的面对面活动。大会当天从 Nicholas Matsakis 和 Aaron Turon 核心团队对我们未来展望开始。演讲幻灯片在此http://rustcamp.com/schedule.html（连同其他几个演讲会谈）。更新：现在你也可以在这 http://confreaks.tv/events/rustcamp2015 看到演讲内容！ 如今有一个确定的主题：Rust 的最大的潜力在于解放新一代的系统编程人员。并且这并不仅仅是语言本身，而只是因为这样的一个社区文化，就如他们所说的：“难道不清楚堆和栈之间的区别吗？不要担心 Rust 是一个最好的方法去学习它，而且我愿意展示给你怎样去使用 Rust。” 我们在上文中提出的技术工作的大纲对我们在 2016 年的版本是很重要的，但是在我们的审核和社区团队方面的工作也一样重要，还有所有那些不辞辛劳和满腔热情地欢迎着来自不同背景的人加入到 Rust 社区中人的工作同样对这个版本很重要。因此，我们最大的愿望是，在 Rust 的下一个年份随着它的社区的成长，它将继续保有着它现在所具有的海纳百川的精神。 |
