#TestableComponentDesign
本文简单介绍了在Rust中编写一个工程性更强的组件(crate)所必须要遵循的一些原则:
Read More
#TiKV #futures
nrc 最近为TiKV的客户端从futures的0.1升级到了0.3,本文记录了该过程中他遇到的一些棘手的问题等。想了解0.1和0.3之间的一些区别,可以看看此文。
#yew #wasm #web
Read More
#rustc
该文作者最近给Rust发了很多PR,用于改进Rust编译器的性能,该文是他对这些PR的一些梳理总结,记录了他提升Rustc编译性能的思路。
Read More
微软安全响应中心一直在研究Rust语言作为系统编程的安全替代方案,并建议整个软件行业认真研究它。并且会写一系列的相关的文章,本文是第一篇:
自2004年以来,微软安全响应中心(MSRC)已经对所有报告的微软安全漏洞进行了三重分析。从所有这些分类中,有一个惊人的事实凸显出来: 正如马特·米勒在2019年布鲁哈特伊利诺伊州的演讲中所讨论的那样,大多数修复的漏洞和分配的CVE漏洞都是由开发人员无意中在他们的C和C++代码中插入内存损坏错误造成的。随着微软增加其代码基础并在其代码中使用更多的开源软件,这个问题并没有变得更好,反而变得更糟。微软并不是唯一一个暴露在内存崩坏问题之下的公司。
所以需要一种更加内存安全的语言,比如Rust。时代在进步和变革,拿汽车和编程语言类比非常适合。我们不是要等事故发生以后再去处理它,而要在事故发生之前,预判一些可能导致事故的危险行为去避免它。
(微软已经不是以前那个微软了,微软越来越像那个我期待的微软了)
Read More
#actix
本文作者尝试解释为什么他不认为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可以更好)
#k8s #Arrow
DataFusion的作者新的项目,目前是PoC(概念验证)阶段。
#tokio
主要是解决tokio用户对依赖tokio时候pull的crate数量抱怨的问题。大家可以来此issues下讨论替代的策略。
(合久必分,分久必合)
Read More
#RustSec
advisory-db
#Carbon
有一个网站叫Carbon,可以创建漂亮的代码图片,而silicon是该功能的Rust实现。
From 日报小组 Chaos
日报订阅地址:
独立日报订阅地址:
社区学习交流平台订阅: