【Rust日报】 2019-06-15：「实录」Rust 和 Go 在图像处理上的性能之争 ...

OStack程序员社区-中国程序员成长平台 › 门户 › 编程› Go›Go教程

原作者: [db:作者] 来自: [db:来源] 收藏邀请

「系列」用Rust写脚本语言

#zhihu #impl_lang

来自国内社区 NameFactory ，他在用Rust实现一门动态语言，并且在知乎里记录了他的心路历程。大家可以关注一下，支持一下。

区块链直播讲座： Web3思想简史——致真正的区块链创业者

今晚8点，Random Capital合伙人刘毅老师会有一场关于web3，substrate方面的讲座，敬请期待

开放社会
密码朋克运动
比特币前传
交易成本
为何是比特币？
超越比特币
世界计算机——以太坊
去中心化的三个维度
后斯诺登时代
Web3及其愿景
Web3应用的特性
Polkadot/Substrate
历史的两条线索
Web3创业者的伴手礼

小鹅通手机直播地址：最好微信打开

「源码阅读」qrcode-rs源码学习分享

「实录」Rust 和 Go 在图像处理上的性能之争

#image #go

这是一次群里讨论的记录。主要问题是：Go和Rust图像处理性能相比如何？（同一场景）

经过作者的测试，发现go的性能更好。

Go耗时：695.732µs
Rust耗时：8 ms （默认release opt-level应该是3）

探究其原因：

Go在处理图片的时候是一次性读到内存里。而Rust是根据图片宽度来进行分行读取。讲道理，Rust的这种处理方式在处理大图片的时候更可取一些。
Rust在使用opt-level 3的release优化下，性能也没有超过Go。查其源码发现是因为Rust的image库，在处理decode的时候存在内存拷贝和内存重分配的问题，应该是导致性能低于Go的原因。

这个案例说明：Rust并不保证默认的实现就是高性能，还需要开发者根据具体的实现来优化。

对此，PingCAP的唐刘大佬说：「嗯，后面我们都可以开一个 talk，如何用 Rust 写高性能代码，在 TiKV 里面不知道踩了多少坑」，这里立个Flag。 PingCAP参加今年的台@@湾开源年会，可能也有相关的主题。

Read

「系列文章」 Rust「封印计划」

#sealed

这是来自于德国柏林一家专注于Rust咨询和服务的公司Ferrous System写的文章。这是系列文章中的第一篇文章，详细介绍了Ferrous System计划对Rust语言和编译器进行安全关键领域认证的计划，这个计划叫做Rust「封印计划」（Sealed Rust）。也就是说，他们要搞起Rust认证了，但这个认证不是对人的认证，而是对Rust语言和编译器，在特定领域上进行安全认证，以便满足特定领域（汽车，工业或航空电子设备等对安全要求更高的领域）的安全需求。

该系列第一篇文章就是描述了该计划的初始流程等内容，感兴趣可以看看。概要：

目前Rust有三种发布状态：Nightly、Beta和Stable。现在Ferrous公司打算提出第四种状态：Sealed。这个版本是从当前Rust中，精选出可以用于特定领域的功能子集，来专门发布一个版本。有点像 #[no_std]，专门用于嵌入式。所以，Sealed就相当于是一种功能的「封印」，这是我把这个计划叫做「封印计划」的原因。现在还不确定这个计划是否会成为Rust开发的一部分，但是该公司首先会进行第一波推动，并且打算和Rust Core团队合作。这个计划也是一个长期的计划，他们在学习Rust edition，计划第一个封印版本在18个月内推出。更多内容请看原文吧。（我个人觉得这个计划很不错）

vrf-rs: 可验证随机函数(VRF) Rust库

#blockchain

是一个快速和可扩展的可验证随机函数(VRF)库，目前支持一些最广泛使用的椭圆密码套件。

六边形架构中应用Rust的自定义派生（derive）宏

#HexagonalArchitecture

该文作者在看《Clean Architecture（整洁架构）》一书中提到的六边形架构的时候所作的一些思考。六边形架构，也叫洋葱架构或端口和适配器架构，这个架构的思想是：拥抱依赖倒置。这非常有利于架构的可扩展性。

作者的这篇文章也酝酿了很久，按他的话说，就是他发现Rust非常适合六边形架构，可以说是最佳选择。原因？

Rust有一个很成熟的模块系统。
Rust对数据和行为的分离的支持是语言级别的。
Rust还允许你通过派生宏（derive）的方式来自动实现一些行为。

所以，作者进一步考察了使用派生宏在六边形架构的Rust代码中是否适合，结论是：

在当前状态下，在Rust代码库中最大限度地使用这样的架构会导致与Rust生态系统中的自定义派生的某些事情产生一些“摩擦”。但是看到Rust发展并在解决这些问题，他感到非常兴奋！

具体案例代码看看原文吧。

Cloaker：非常简单的基于密码的跨平台文件加密工具

#FileEncryption

核心是Rust实现，GUI是基于CFC/MFC和Qt实现。

cloaker

Rust隐藏的天赋：加速构建和版本管理

#tips

该文介绍了基于Global build cache来加速编译的一个小技巧，但也有三点重要的注意事项。另外的替代方案是使用Mozilla出品的sccache工具。

介绍 actix-irc

#actix #irc

基于actix和irc库实现的一个irc协议库。

一种用于太空应用的编程语言

这篇文章开篇抛出一个有趣的问题：

在一个纯粹的假设场景中，太空中有一颗小卫星可以让地球上的人在其机载计算机上上传和运行自己的任务软件。然后，用户将能够控制卫星子系统。选择哪门编程语言最好？以允许人们编写这样的软件，而不用担心过早结束任务？

要求：

首先，任何语言的主要必要性是匹配应用程序的所属领域。可以将空间任务软件视为基于事件驱动的基于状态的体系结构，其中至少有部分代码在硬实时下运行，某些任务活动只能在特定条件下进行。生存任务要优先于科学或其他活动。因此，任务的软件开发过程需要生成特别健壮的代码，这些代码有望在预期和非预期的场景中均可执行。语言工具和语义都必须能够强制执行编写软件产品代码所需要的规范。

其次，与许多地面计算机相比，卫星车载计算机在可用硬件资源方面的限制增加，特别是如果所讨论的卫星是具有有限功率和计算预算的CubeSat（立方体卫星，低成本微卫星，计算资源有限）。有效的资源利用率必须是语言功能的一部分，可直接控制内存分配和CPU周期。

第三，应该对卫星上使用的硬件和软件功能提供足够的支持。如果要考虑CubeSat，则应包括嵌入式通信总线，如I2C，SPI和CAN，以及可能需要实现自定义驱动程序的许多不同硬件外围设备。现代纳米卫星中常用的操作系统是FreeRTOS和Linux，通常是一种ARM微处理器。

最后，用这种编程语言编写代码应该很有趣。我们希望没有太空产业的人们亲身体验太空探索;他们不应该对现代航空航天软件开发过程感到沮丧和恐惧。如果修补自制硬件和软件的人不喜欢这样做，那么70年代和80年代的计算机革命就不可能实现。即使编程航天器是一项关键任务活动，如果我们希望在航天工业中发生类似的革命，也不应感到痛苦和无助。

(感觉就是为Rust量身定制的问题？)

该问题我也发到了知乎：https://www.zhihu.com/question/329522820 ，欢迎大家讨论。

来看看本文作者怎么说？