【Rust日报】 2019-07-17：微软安全响应中心：一种主动性的方式来提升安全

本文主要是介绍【Rust日报】 2019-07-17：微软安全响应中心：一种主动性的方式来提升安全，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Rust的可测试组件设计

#TestableComponentDesign

本文简单介绍了在Rust中编写一个工程性更强的组件（crate）所必须要遵循的一些原则：

自动化测试覆盖
需要可配置的依赖
公共api应该更加易于使用和理解
契约层应该尽量减少泛型的使用
其他

从futures 0.1迁移到0.3

#TiKV #futures

nrc 最近为TiKV的客户端从futures的0.1升级到了0.3，本文记录了该过程中他遇到的一些棘手的问题等。想了解0.1和0.3之间的一些区别，可以看看此文。

Read More
client-rust

使用Yew和Rust进行全栈Web开发

#yew #wasm #web

2019年如何提升Rust编译器性能

#rustc

该文作者最近给Rust发了很多PR，用于改进Rust编译器的性能，该文是他对这些PR的一些梳理总结，记录了他提升Rustc编译性能的思路。

「系列文章」微软安全响应中心：一种主动性的方式来提升安全

微软安全响应中心一直在研究Rust语言作为系统编程的安全替代方案，并建议整个软件行业认真研究它。并且会写一系列的相关的文章，本文是第一篇：

自2004年以来，微软安全响应中心(MSRC)已经对所有报告的微软安全漏洞进行了三重分析。从所有这些分类中，有一个惊人的事实凸显出来: 正如马特·米勒在2019年布鲁哈特伊利诺伊州的演讲中所讨论的那样，大多数修复的漏洞和分配的CVE漏洞都是由开发人员无意中在他们的C和C++代码中插入内存损坏错误造成的。随着微软增加其代码基础并在其代码中使用更多的开源软件，这个问题并没有变得更好，反而变得更糟。微软并不是唯一一个暴露在内存崩坏问题之下的公司。

所以需要一种更加内存安全的语言，比如Rust。时代在进步和变革，拿汽车和编程语言类比非常适合。我们不是要等事故发生以后再去处理它，而要在事故发生之前，预判一些可能导致事故的危险行为去避免它。

(微软已经不是以前那个微软了，微软越来越像那个我期待的微软了)

叫板？为什么我们需要一个actix的替代品

#actix

本文作者尝试解释为什么他不认为actix-web能够成为引领Rust社区向前发展的“那个”框架。作者列出了他的理由：

代码中依旧还有25个unsafe方法在使用。比如std::mem::uninitialized。但有人可能会说，这没什么大不了的，修好就可以了。但是本文作者强调：Nikolay（acitx-web作者）的态度是你难以改变的。本文作者列举了Nikolay在强硬关闭其他人移除actix-web中unsafe代码的PR中的回复：actix-web/pull/968。（这个PR下actix-web作者的几个回复的态度确实不太好，比如他说道：已经失去了和开源社区打交道的动力。）
actix不是一个你可以轻易贡献的项目。最终，这使得开发者都将依赖Nikolay来获得新的特性。本文作者用一个词来描述actix-web：Flying Solo。
性能测试作弊？比如硬编码header值、或者放弃检查HTTP方法之类。他呼吁大家仔细研究下TechEmpower的测试代码。

总结：本文作者认为actix-web作者的心态和代码内部的质量，足以让他放弃actix框架。那么还有哪些替代品？