Rust 1.0 发布一周年,发展回顾与总结

阅读数:2791 2016 年 6 月 16 日 17:42

前言

Rust 1.0 发布刚刚一周年(2015.5~2016.5),这一年来 Rust 又取得了长足的进步。笔者尝试从多个方面总结过去一年来 Rust 领域的重要动作、进度和成就。本文内容丰富,信息量大,总结比较全面。读者从中可以看到:开发者的辛勤努力和 Rust 语言的快速成长,Dropbox 等公司在生产环境中的核心模块应用 Rust,社区成员积极参与社区活动,Rust 在国内的发展状况,等等。

Rust 语言 / 编译器 / 标准库升级

一些零散的升级,像添加 Stable API、局部提升性能、修改某些 BUG 等等,在这里就不提了。我将要说的,都是影响深远的重大升级。当然,还有很多工作未最终完成,要等以后的版本问世。但是前期的研究、讨论、设计等步骤基本走完,剩下的无非就是编码实现、实验性应用、标准化等步骤,只要没有意外,后面的一切都顺理成章。

本文多次提及的 RFCs ,后面将有专门章节介绍,此处不展开叙述。

impl specialization (RFC 1210)

这一特性类似 C++ 的模板特化和偏特化。允许为接口或类型定义多个可重叠的impl实现,最终由编译器依据上下文自动选择其中一个最具体、最 specific(general 的对立面)的实现。它能帮助程序员更好的优化性能、重用代码,还为将来实现规划已久的"efficient inheritance"提供基础支持。

举个简单的例子。Rust 从 1.0 开始就为 “实现了Display接口的任意类型 T”

实现了ToString接口。这是一个泛型实现,涉及大量类型,覆盖面很广。从代码实现细节上看,用到格式化文本输出( fmt::Write::write_fmt )。

#[stable(feature = "rust1", since = "1.0.0")]
impl<T: fmt::Display + ?Sized> ToString for T {
    #[inline]
    default fn to_string(&self) -> String {
        use core::fmt::Write;
        let mut buf = String::new();
        let _ = buf.write_fmt(format_args!("{}", self));
        buf.shrink_to_fit();
        buf
    }
}

具体到基础字符串类型str,它当然也属于上面提及的 “实现了Display接口的任意类型 T”,因而自动实现ToString接口,拥有to_string方法。然而上面的实现代码里的格式化输出功能对于 str 转换至 String 来说是多余的,带来额外的运行时开销,因而导致"str".to_string()"str".to_owned()更慢这种很尴尬的局面,持续了一年多时间。

Rust 语言支持 impl specialization 特性之后,就可以在标准库里为str类型添加一个更具体、更 specific 的 ToString 实现:

impl ToString for str {
    #[inline]
    fn to_string(&self) -> String {
        String::from(self)
    }
}

impl specialization (RFC 1210) 设计稿自 2015 年 6 月推出第一版,至 2016 年 2 月,期间经过及其广泛而深入的高质量的公开的设计讨论,数易其稿,最终被正式批准采纳。2016 年3 月,该设计稿被部分实现 impl ToString for str已经成为现实。

foo?.bar()? (RFC 243)

Rust 现有的错误处理机制( try! + Result )虽然还不错,但是使用有些繁琐,对链式调用不友好。try!不是语言内置特性,而只是标准库里定义的一个很简单的宏。长期以来,Rust 开发者一直在寻找更好更简洁的错误处理机制,进行了许多探索和讨论。2014 年 9 月 RFC 243 被提出,2015 年 10 月经过重大设计改进,2016 年 2 月被正式采纳,3 月被初步实现,期间经过大量设计讨论。至今 foo?.bar()?语法已经待在 nightly 版本里被内部测试三个月时间,如果不出意外估计不久就会进入 stable 版本跟大家正式见面。发布之前要做的其中一项工作将是把标准库里面的try!全面切换到?(已经有自动化工具 untry 可用)。这一特性毫无疑问将改变所有人编写代码的方式。

MIR (RFC 1211)

现在的 Rust 编译器,是从 2010 年开始开发的,是用 2010 年的 Rust 语言编写的。那个时候,Rust 的 0.1 版本都还没出娘胎呢。此后的 5 年时间里,Rust 语言在进化过程中不断地发生天翻地覆的变动。Rust 编译器正是在这样动荡的环境下逐步迭代完成开发。我们认为,Rust 编译器是由许多个不同版本的 Rust 语言写成的;甚至可以说,Rust 编译器是由许多不同的编程语言写成的(因为每个版本的变化都非常大)。结果就是,在编译器源代码的角落里,难免存在一些陈旧代码和历史遗留问题,并在一定程度上阻碍了编译器的维护和升级。

MIR 计划正是在这样的背景下诞生的。通过在编译器内部引入中层中间表示码(Mid-level Intermediate Representation,介于上层 HIR 和底层 LLVM IR 之间),对编译器代码进行大型重构、改造。这一基础性的改进,对编译器今后的维护、升级,具有深远的影响。许多新特性可在 MIR 的基础上更方便的实现。例如,增量编译、代码优化、更精确的类型检查等等( Non-zeroing drop , Non-lexical lifetimes ),都依赖于 MIR 计划的实施。开发者甚至在计划借助 MIR 直接生成 WebAssembly 字节码并已着手行动(WebAssembly:JavaScript 垄断地位的终结者)。

2015 年 7、8 月份完成 MIR 的设计,此后很快进入长达十个月的编码实施阶段。任务量非常大,但进展有条不紊,Github 忠实记录了一切。到 2016 年 5 月份,MIR 代码生成工作基本完成,基于 MIR 的进一步优化和应用,尚在进行中。

alloctors (RFC 1398 1183)

2014 年 4 月提出的 RFC PR 39 未获通过,同年 9 月的 RFC PR 224 也未获通过,直到 2015 年 12 月的 RFC 1398 终于有所斩获,在历经数十次修订后,于 2016 年 4 月修成正果,成为内存分配器标准接口的正式规范,为今后开发者自行实现各种类型的内存分配器扫清了障碍。其背后的动机是,系统默认提供的内存分配器(例如 jemalloc)不可能适合所有应用场景,第三方内存分配器的引入是必要的。

从整个漫长过程我们看到设计的艰难、设计者的不懈努力,和坚持追求高质量设计的严肃态度。

于此同时,允许变更系统默认内存分配器的设计工作也被提上日程。 RFC 1183 在 2015 年 7 月推出设计稿,一个月后获得官方审核批准。8 月份修改编译器,完成编码工作,完整地实现了此 RFC。jemalloc 不再是强制使用的内存分配器,程序员有机会选择使用其他内存分配器作为默认内存分配器。这一功能已被内部测试了将近一年,预计不久之后将会正式发布。

编译错误提示

编译错误提示更加简洁和人性化。

以前:

(点击放大图像)

现在:

(点击放大图像)

2016 年 5 月初,此功能已经在 nightly 版本中实现。再经过一段时间的培育,确认其稳定工作之后,将会进入 stable 版本正式面世。(注,上面的附图是稍早的版本,后面又有所调整和改进。)

其他

  • 增量编译( Incremental compilation ):2015 年 8 月至 11 月完成增量编译的设计文档( RFC 1298 )。相关编码实现工作缓慢进展,部分依赖于 MIR。

  • Macro 2.0:新一代宏 2.0 的规划和设计取得较大进展, nrc 做了大量的前期研究工作,提出了设计稿 RFC PR 1566 。接下去的进展有待观察。

  • impl Trait: 取得了许多探索和研究成果( 1 2 3 ), RFC PR 1522 得到了比较广泛的认同,很快会有下一步的动作。完成之后将改善“函数返回迭代器”的现状(struct 扎堆)。

  • 单指令多数据( SIMD ): Rust 对 SIMD 硬件加速支持取得初步进展,huonw 做了大量前期工作,提出 RFC 1199 (2015 年 9 月获得批准),提交基础实现扩展库。属于实验性支持阶段,已在regex 库中得到应用(性能提升十分明显)。

Rust 周边开发工具升级

Cargo

  • cargo install : 只需一个很简单的命令(cargo install xxx)就能编译安装可执行程序到本地.cargo/bin目录(此目录一般都在 PATH 环境变量内)。设计和实现均已完成。像 clippy , rustfmt , cargo-edit 等都能通过它安装,十分方便。

  • cargo workspace : 让 Rust 项目的源代码目录结构和布局更加灵活。设计完成但尚未实现(在本文创作后期已经实现)。

  • cargo concurrently : 允许多个 Cargo 实例并发执行。已经初步完成。

  • cargo namespacing : 官方开发者始终持有主动排斥的不作为态度,因而一年来没有任何进展。跟 Go 语言泛型面临的悲催处境惊人的相似。

clippy

clippy 得到了许多人发自内心的喜爱。它会分析审查你的源代码,并提出许多贴心的改进意见。它像良师益友,安静地坐在你身边,面对面指导你编写代码。经常使用它,有助于改善代码质量、提升开发者的编程经验和水平,无论新手老手都能从中受益。

Thanks rust-clippy . We do love the great project.

安装方法:cargo install clippy;使用方法:cargo clippy

rustfmt

格式化 Rust 源代码的工具,已经基本成熟、稳定可用,许多官方库用它格式化代码。不过它存在的意义相比clippy 弱暴了。 rustfmt 只是辅助修整一些皮面而已,对语意几乎一窍不通,我想不通某些哥们经常对这类工具推崇备至。安装方法:cargo install rustfmt;使用方法:cargo fmtrustfmt

rustup

Rust 安装和更新工具,可以方便的切换 stable 和 nightly 版本,可以下载和使用各种平台交叉编译工具链。前身是 Shell 脚本,现在已经是纯 Rust 开发 ( rustup.rs )。开发者首选的 Rust 安装方式。这里还要顺便提及 brson 为方便各操作系统打包 Rust 所付出的努力

rustbuild

专为 Rust 编译器和标准库定制的基于 Cargo 的编译工具,用于取代之前基于 Makefile 的编译系统(已经过于庞大和复杂难以维护)。已经做了大量前期工作

Editors & IDEs

各主流代码编辑器 /IDE 都对 Rust 提供或多或少的某种程度的支持。语法高亮着色、代码自动完成等基本功能都已实现。 RFC 1317 讨论)还进行了深入的思考和规划,未来 Rust 编译器和其他工具将主动对 IDE 提供更友好的支持(但是目前还没有看到具体的动作)。

详情可参考 Are we IDE yet ,或参见 Reddit 网友讨论帖: Show me your programming environment 。官方网站也有总结

以上几乎所有编辑器 &IDE 及其插件的背后都离不开大功臣 Racer :Rust“代码提示 & 自动完成”工具。

我现在感觉用 VSCode v1.2 比较顺手,比 Atom v1.8 反应快还更稳定。作为通用的代码编辑器,我原本对 Atom 寄予厚望,但现在来看 VSCode 有后来居上的趋势。

Rust 第三方应用升级

Dropbox Magic-Pocket

2016 年 3 月份, Dropbox 公司脱离 Amazon 云存储平台的战略规划和实施细节浮出水面(低调做事之后高调发布,这风格我喜欢)。国际新闻报道标题是:"The Epic Story of Dropbox’s Exodus From the Amazon Cloud Empire"英文讨论)。国内新闻报道标题是:“Dropbox 用 Rust 取代 Go 精简内存占用”中文讨论)。Dropbox 这一计划的核心是自己开发云存储系统,并逐步过渡。一开始是用Golang 语言开发,后来上线后发现系统占用内存太厉害,于是改用Rust 语言开发该系统的核心模块 Magic Pocket 。对外报道时,新系统已经上线一段时间,运行状况良好。

Redox OS

Redox OS 是真撸啊。想搞另一个 Linux 出来。

用 Rust 语言开发的 Redox 操作系统,2015 年 9 月一经面世就拥有图形用户界面,现已实现文件系统(ZFS WIP)、网络系统、多线程、文本编辑器等等。微内核设计,硬件驱动运行在用户空间。兼容大多数Linux系统调用和常见的 Unix 命令

它可在 Linux、Windows、OS X 上编译,可在真实硬件上 (Panasonic TOUGHBOOK CF-18、IBM Thinkpad T-420、ASUS eeePC 900) 启动并运行 GUI 应用和 Console 应用。一个团队还在不断的开发完善 Redox 系统。开发活跃,进展很快,文档较全。

个人或小团队开发出来的绝大多数所谓的操作系统,都是习作、玩具。那些借助 BootLoader 启动起来并在屏幕上输出文字的所谓内核,除了作为新手入门练习之外没有任何应用价值。Redox 显然不属于此类,Redox 有更高的追求。Redox 的作者也不是新手,而是资深的 OS 开发专家。

Redox OS 固然牛逼,可它也不是一个人在战斗,用 Rust 开发的操作系统有好几个呢。

TiKV 分布式存储引擎

PingCAP 公司推出的 TiDB 是开源的分布式数据库,参考 Google F1/Spanner 实现了水平伸缩,一致性的分布式事务,多副本同步复制等重要 NewSQL 特性。结合了 RDBMS 和 NoSQL 的优点,同时完全兼容 MySQL。前期用 Go 语言实现了 SQL Layer,后来 (2015 年底) 考虑到“Go 的 GC 和 Runtime 对底层存储非常不友好”,再加上对运行效率的极致要求,决定采用 Rust 语言开发 TiDB 的核心存储模块 TiKV 。2016 年 1 月份至今,TiKV 项目的开发十分活跃,至少有 4 位软件工程师全职参与开发。4 月份刚刚开源。

Diesel ORM

作者 Sean Griffin 是 Ruby Rails ActiveRecord 的现任活跃维护者,是ORM 领域的专家。他在2015 年9 月启动 Diesel 项目。来自 ActiveRecord 的优秀设计、经验和教训,有助于他设计实现这个全新的 ORM 项目。Diesel 项目的设计充分发挥 Rust 类型安全的优势,还特别注重性能和可扩展性,文档也不错。是颇受关注、值得期待的项目。

在生产环境中使用 Rust

Rust 官方网站专门有一个页面, Friends of Rust (2016 年 4 月底上线,持续更新),列出了在生产环境中使用 Rust 语言的组织和项目。

其中 MaidSafe 是有野心的项目,这一年来一直持续开发。 Servo 也是;而且会有越来越多的 Rust 开发的 Servo 组件迁入 Firefox 浏览器。

其他潜力股项目

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 )

Libraries like crossbeam are probably more appropriate for the std. Lock-free containers(data structures). ( LilianMoraru )

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 )

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)

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 提供的这幅图十分形象的揭示了这一机制工作原理。

(点击放大图像)

这种机制的好处是,在保证产品稳定性的前提下提供较频繁且平滑的升级体验。让用户没有心理负担地升级,乐于使用最新稳定版本,而不是像 Java 那样总想着憋 N 年搞一个大新闻出来,反而让某些用户有升级恐惧症。喜欢尝鲜的 Rust 用户,可以选用每日更新的 nightly 版本(或 beta 版本)。两边都不耽误。

RFCs

Rust 早在 2014 年就开始逐步实施 RFC 机制。要求对代码做出重大改动或提议增加重要特性之前,发起者需要首先写出设计文档(即所谓“请求讨论稿” - Request For Comments),经过公开讨论逐步修正完善,并得到核心专家组批准之后,才能进入下一步编写代码实现功能阶段,最后还有一个标准化步骤,直至进入正式发行版 (stable)。

这一机制的好处是:

  • 强调设计在编码之前
  • 强调公开的设计、公开的讨论、广泛地征求意见
  • 强调核心专家组对设计方向和质量的把控
  • 有利于积累专业的技术设计文档
  • 避免某些模块的设计仅有个别人理解
  • 提高代码的可审查性和可维护性
  • 保证项目的高质量和发展方向
  • 配合 Feature-gate 确保实验性项目在实验期间不流出实验室

这对开源软件的健康发展是至关重要的。别的项目也开始认可这一点,并参考实施,例如:

注:目前不能证实微软 F#项目的 RFC 机制源于 Rust。运作机制虽有所不同,但设计在前、公开讨论、官方审核等核心内容是一致的;RFC 文本结构相似度很高。多讲一句,说起来 F#和 Rust 还是亲戚呢,语言设计层面都跟 OCaml 语言有很深的渊源,Rust 最初版本的编译器还是用 OCaml 开发的(当然现在早就换成 Rust 开发了)。

本周更新公告 (This Week In XX)

This Week In Rust ”每周推出一期,总结介绍上一周 Rust 发生的重要事件,如功能增加或变动,新的设计文档 (RFC) 得到批准,谁发表了重要文章,谁举行了聚会等等。从 2013 年 6 月 Rust 推出第一期“This Week In Rust”开始,三年来共发布 130 期(其中在 1.0 之后发布约 50 期)。可以当作新闻报纸摘要来读,用户花少量的时间就能了解 Rust 重要开发动态。

后来有些项目开始学习这种公告形式:

这种事情最难得的就是持之以恒。Rust 出到第 130 期了,Servo 出到第 62 期了,Redox 出到第 14 期了,加油吧。(注:因本文创作时间跨度较大,以上数据可能稍有过时。)

别的项目没有(各种形式的)每周(或每月)更新公告,其中一个理由可以理解为:开发活跃度低,每周更新的内容少,不好意思写出来;或者被关注度低,写出来也没多少人看,所以干脆不写了;再或者开发透明度低,不能写出来给人看。(唉,人艰不拆,说出实话就要得罪人!

支援兄弟语言项目

本着共建和谐开源大家庭原则,Rust 社区充分发扬共产主义精神,积极参与其他社区活动,为各兄弟语言项目送温暖、献爱心,共享发展理念,致力于实现共同富裕。Rust 在安全和性能方面优势非常突出,尤其适合为其他语言编写 Native 扩展库。下面提到的项目多是名家作品。

Lua

有过 Lua 本地模块开发经历( htmlua iedom )的我,第一次看到 hlua 就有眼前一亮的感觉,眼珠子都快掉下来了,惊叹居然可以这样写 Lua 的本地扩展模块,完全突破了 Lua C API 的死板接口:

#![feature(phase)]
#[!plugin(rust-hl-lua-modules)]

#[export_lua_module]
pub mod mylib {         // <-- must be the name of the Lua module
    static PI: f32 = 3.141592;

    fn function1(a: int, b: int) -> int {
        a + b
    }

    fn function2(a: int) -> int {
        a + 5
    }

    #[lua_module_init]
    fn init() {
        println!("module initialized!")
    }
}

hlua 的作者是何方大神?这里先卖个关子。后面他还会出现。

Ruby

借助 helix 项目,让 Rust 语言编写 Ruby 本地库变得很简单, 消除了大量胶水代码。

declare_types! {
    class Console {
        def log(self, string: &str) {
            println!("LOG: {}", string);
        }
    }
}
$ irb
>> require "console/native"
>> Console.new.log("I'm in your rust")
LOG: I'm in your Rust

Helix 的作者是 Rust 核心开发者 Yehuda Katz 和 Ruby on Rails 核心开发者 Godfrey Chan 。这个阵容够强大吧?

Node.js

通过 neon 项目,用 Rust 语言编写 Node.js 本地扩展包,既简化了代码编写,又简化了编译过程。看看它的 demo ,让人印象深刻:静态编译 + 并发计算,性能远超 JavaScript,强到没朋友。简单贴一段代码:

fn search(call: Call) -> JsResult<JsInteger> {
    let scope = call.scope;
    let buffer: Handle<JsBuffer> = try!(try!(call.arguments.require(scope, 0)).check::<JsBuffer>());
    let string: Handle<JsString> = try!(try!(call.arguments.require(scope, 1)).check::<JsString>());
    let search = &string.data()[..];
    let total = vm::lock(buffer, |data| {
        let corpus = data.as_str().unwrap();
        wc_parallel(&lines(corpus), search)
    });
    Ok(JsInteger::new(scope, total))
}

register_module!(m, {
    m.export("search", search)
});

Neno 的核心开发者 Dave Herman ,是 Mozilla 公司员工,ASM.js 的作者,牛逼的不要不要的。

Golang

通过 rure 项目,Rust 给 Go 语言送去性能更强的正则表达式库,让Go 社区的同学们提前用上高大上的 lazy DFA 特性。

Rure 的作者 Andrew Gallant ,是 Rust 开发组成员,Rust Regex Docopt 库的主要作者。

Python

rust-cpython 使得采用 Rust 语言编写 Python 扩展库和调用 Python 代码成为现实。

#![crate_type = "dylib"]
#[macro_use] extern crate cpython;
use cpython::{Python, PyResult, PyObject};

py_module_initializer!(example, initexample, PyInit_example, |py, m| {
    try!(m.add(py, "__doc__", "Module documentation string"));
    try!(m.add(py, "run", py_fn!(py, run())));
    Ok(())
});

fn run(py: Python) -> PyResult<PyObject> {
    println!("Rust says: Hello Python!");
    Ok(py.None())
}

Erlang and Elixir

Rustler 使得 Rust 可以轻松编写 Erlang NIF(本地实现函数库)。

#![feature(plugin)]
#![plugin(rustler_codegen)]

#[macro_use]
extern crate rustler;
use rustler::{ NifEnv, NifTerm, NifResult, NifEncoder };

rustler_export_nifs!(
    "Elixir.TestNifModule",
    [("add", 2, add)],
    None
);

fn add<'a>(env: &'a NifEnv, args: &Vec<NifTerm>) -> NifResult<NifTerm<'a>> {
    let num1: i64 = try!(args[0].decode());
    let num2: i64 = try!(args[1].decode());
    Ok((num1 + num2).encode(env))
}

C and others

C 同学也未被遗忘,Rust 双手奉上 Regex C API ,并希望 C 同学向各编程语言转达来自 Rust 语言的问候。Servo 也有提供 C API

Rust 语言内置支持与 C 语言的互相调用( FFI )。其他语言以 C 为中介可间接地实现与 Rust 交互。对于 Rust 调用 C 库的情况, rust-bindgen 很给力,可自动生成 Rust 端调用接口。新特性 cdylib 使得 Rust 编译出的 DLL/SO 文件尺寸更加小巧,更方便被其他语言嵌入、调用。Rust 当然也支持引入和输出静态库 lib 文件。

Vulkan

Vulkan 规范今年 2 月份刚发布,Rust 迅速跟进,很快就有了安全而高效的 vulkano 第三方封装库。

vulkano 的作者 tomaka ,同时也是大名鼎鼎的 glium 和前面提到的 hlua 的作者。

最受群众喜爱的编程语言

在国际知名网站 StackOverlow 主办的 2016 年开发者调查报告中,Rust 荣获最受群众喜爱的编程语言大奖。群众的眼光是雪亮的。

Rust 在国内的发展情况

后语

Rust 语言还是成长中的孩子。它有已经成熟的一面,且持续保持稳定,经历过至少一年的时间考验,证明它初步拥有独当一面的能力。它还有欠缺的一面,许多地方有待完善和拓展,它正视自身存在的问题,从多方面努力争取拿出最好的解决方案。过去一年的主题可以总结为:巩固已经稳定成熟的领域,发展全新的领域或有欠缺的领域。Rust 开发者们卓有成效的工作,使得 Rust 取得了可喜的进步,让我们对 Rust 的未来充满信心。Rust 社区高度活跃的现状昭示着我们不是一个人在战斗。Dropbox 等公司的加入使得队伍不断扩大。继续努力吧,务实的 Rust 编程语言,我们期待下一年取得更大的进展。

参考:


感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

评论

发布