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

本文为InfoQ中文站特供稿件,首发地址为: http://www.infoq.com/cn/articles/anniversary-of-the-release-of-rust-1 。如需转载,请与InfoQ中文站联系。原文发表于2016年6月17日,40日后根据之前约定将其全文转发到我(Liigo)个人博客里。此文创作于今年5月份(5月初至6月初),过程颇为周折,没赶上Rust 1.0纪念日,可谓姗姗来迟也。

前言

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

release channels

这种机制的好处是,在保证产品稳定性的前提下提供较频繁且平滑的升级体验。让用户没有心理负担地升级,乐于使用最新稳定版本,而不是像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 RegexDocopt库的主要作者。

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编程语言,我们期待下一年取得更大的进展。

参考:

猜你喜欢

转载自blog.csdn.net/liigo/article/details/52050252