本文简单介绍了在Rust中编写一个工程性更强的组件（crate）所必须要遵循的一些原则：
nrc 最近为TiKV的客户端从futures的0.1升级到了0.3，本文记录了该过程中他遇到的一些棘手的问题等。想了解0.1和0.3之间的一些区别，可以看看此文。
该文作者最近给Rust发了很多PR，用于改进Rust编译器的性能，该文是他对这些PR的一些梳理总结，记录了他提升Rustc编译性能的思路。
微软安全响应中心一直在研究Rust语言作为系统编程的安全替代方案，并建议整个软件行业认真研究它。并且会写一系列的相关的文章，本文是第一篇：
自2004年以来，微软安全响应中心(MSRC)已经对所有报告的微软安全漏洞进行了三重分析。从所有这些分类中，有一个惊人的事实凸显出来:
正如马特·米勒在2019年布鲁哈特伊利诺伊州的演讲中所讨论的那样，大多数修复的漏洞和分配的CVE漏洞都是由开发人员无意中在他们的C和C++代码中插入内存损坏错误造成的。随着微软增加其代码基础并在其代码中使用更多的开源软件，这个问题并没有变得更好，反而变得更糟。微软并不是唯一一个暴露在内存崩坏问题之下的公司。
所以需要一种更加内存安全的语言，比如Rust。时代在进步和变革，拿汽车和编程语言类比非常适合。我们不是要等事故发生以后再去处理它，而要在事故发生之前，预判一些可能导致事故的危险行为去避免它。
(微软已经不是以前那个微软了，微软越来越像那个我期待的微软了)
本文作者尝试解释为什么他不认为actix-web能够成为引领Rust社区向前发展的“那个”框架。作者列出了他的理由：
std::mem::uninitialized。但有人可能会说，这没什么大不了的，修好就可以了。但是本文作者强调：Nikolay（acitx-web作者）的态度是你难以改变的。本文作者列举了Nikolay在强硬关闭其他人移除actix-web中unsafe代码的PR中的回复：actix-web/pull/968。 （这个PR下actix-web作者的几个回复的态度确实不太好，比如他说道：已经失去了和开源社区打交道的动力。）总结：本文作者认为actix-web作者的心态和代码内部的质量，足以让他放弃actix框架。那么还有哪些替代品？
(wow，看完之后我感觉，该文作者描述actix的问题还是挺严重的，真心希望actix-web可以更好)
DataFusion的作者新的项目，目前是PoC（概念验证）阶段。
主要是解决tokio用户对依赖tokio时候pull的crate数量抱怨的问题。大家可以来此issues下讨论替代的策略。
（合久必分，分久必合）
有一个网站叫Carbon，可以创建漂亮的代码图片，而silicon是该功能的Rust实现。
From 日报小组 Chaos
日报订阅地址：
独立日报订阅地址：
社区学习交流平台订阅：