Rust的可测试组件设计
本文简单介绍了在Rust中编写一个工程性更强的组件（crate）所必须要遵循的一些原则：
- 自动化测试覆盖
- 需要可配置的依赖
- 公共api应该更加易于使用和理解
- 契约层应该尽量减少泛型的使用
- 其他
从futures 0.1迁移到0.3
nrc 最近为TiKV的客户端从futures的0.1升级到了0.3，本文记录了该过程中他遇到的一些棘手的问题等。想了解0.1和0.3之间的一些区别，可以看看此文。
使用Yew和Rust进行全栈Web开发
2019年如何提升Rust编译器性能
该文作者最近给Rust发了很多PR，用于改进Rust编译器的性能，该文是他对这些PR的一些梳理总结，记录了他提升Rustc编译性能的思路。
「系列文章」微软安全响应中心：一种主动性的方式来提升安全
微软安全响应中心一直在研究Rust语言作为系统编程的安全替代方案，并建议整个软件行业认真研究它。并且会写一系列的相关的文章，本文是第一篇：
自2004年以来，微软安全响应中心(MSRC)已经对所有报告的微软安全漏洞进行了三重分析。从所有这些分类中，有一个惊人的事实凸显出来:
正如马特·米勒在2019年布鲁哈特伊利诺伊州的演讲中所讨论的那样，大多数修复的漏洞和分配的CVE漏洞都是由开发人员无意中在他们的C和C++代码中插入内存损坏错误造成的。随着微软增加其代码基础并在其代码中使用更多的开源软件，这个问题并没有变得更好，反而变得更糟。微软并不是唯一一个暴露在内存崩坏问题之下的公司。
所以需要一种更加内存安全的语言，比如Rust。时代在进步和变革，拿汽车和编程语言类比非常适合。我们不是要等事故发生以后再去处理它，而要在事故发生之前，预判一些可能导致事故的危险行为去避免它。
(微软已经不是以前那个微软了，微软越来越像那个我期待的微软了)
叫板？为什么我们需要一个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框架。那么还有哪些替代品？
- Rocket
- Gotham
- Thruster
- Warp
- Tide
(wow，看完之后我感觉，该文作者描述actix的问题还是挺严重的，真心希望actix-web可以更好)
Ballista：集成了Rust、 Apache Arrow 和 Kubernetes的分布式计算平台
DataFusion的作者新的项目，目前是PoC（概念验证）阶段。
tokio重构计划：让tokio 的子crate “坍缩”为一个独立的crate
主要是解决tokio用户对依赖tokio时候pull的crate数量抱怨的问题。大家可以来此issues下讨论替代的策略。
（合久必分，分久必合）
advisory-db: RustSec组织发布的安全告警数据库
silicon: 为你的源码创建漂亮的图片
有一个网站叫Carbon，可以创建漂亮的代码图片，而silicon是该功能的Rust实现。
From 日报小组 Chaos
日报订阅地址：
独立日报订阅地址：
社区学习交流平台订阅：