可以关注下这个知乎问题，下面链接是对区块链框架CITA的介绍。
nom是Rust社区的一个重要的解析工具，作者在reddit发帖表示将要发布5.0版本。（这是一个你没有看过的船新版本，挤需体验三分钟，里造会干我一样，爱象这个版本。）
你可以在nomfun项目里体验到nom的新设计。在这个库里完全看不到宏的影子了，取而代之的是Functor，用法和另一个解析库combine趋于一致。新版本据说性能会有5%-20%的提升，并且有更好的错误处理系统，同时保持大部分向后兼容。因为作者家里有事，可能5.0版本需要几个月才能发布，不过近期他会先发一个alpha版本，作者也列出了一个5.0的路线图。
可以很轻松地集成CI。
ArcSwap可以自动存储和加载Arc，类似于RwLock<Arc <T >>但没有锁。适合于频繁读取但不经常修改的数据，如配置或内存数据库每秒请求数百万次查询等。这篇文章中，作者揭示了ArcSwap的工作机制。
#error_handle
failure + error-chain = <3
这个库旨在提升failure的用户体验（error_chain向）。
有人在reddit发帖，探讨了他目前观察到Rust的一些状态，他关注的点是：
结论： 目前Rust生态已经处在一种「马上能成事」的边缘。作者表示，如果现在用Rust构建他想要实现的产品，可能需要自己构建或者等待一些工具（大约一年）。他也知道现在开始学习Rust正好，也可以提交一些PR来改进生态，但是他不想这样（233，估计是时间关系），然而他说，他可以出钱赞助这些加速生态发展的项目维护者。
默认情况下，serde在序列化结构时包括所有字段，即使它们的值是默认值。 这可能导致一些包含空值的「污染」。本篇文章教你如何跳过这些默认值。
#best_practices
有人在reddit上面开贴询问这个问题，评论里也有很多人讨论。大家还有什么推荐？
（我个人用的是dotenv了）
Linkerd的服务之前是Scala写的，并且受到了Twitter在Finagle RFC系统上工作的启发。但是Linkerd 2却用Go（Control Plane）和Rust（Data Plane）进行了重写。
（这让我想到Twitter曾经宣布用Scala/Java替换Ruby的新闻，感受到了时代的车轮在转动。本文作者是Buoyant的CEO和联合创始人。在加入Buoyant之前，他是Twitter的基础架构工程师，就是他帮助将Twitter从一个失败的单片Ruby on Rails应用程序迁移到基于Scala的高度分布式，容错的微服务架构）
Buoyant团队对底层的Rust网络堆栈进行了深入的技术投资，并将UX重新定位于简单性，易用性和低认知开销上。结果显着更快，更轻，更简单。
自Linkerd 2.0发布至今已有六个多月，该团队认为重写已经带来了好处，许多以前无法采用1.x分支的用户现在乐于采用2.x。
Linkerd团队从1.0产品中吸取了什么教训？
尽管Linkerd取得了成功，但许多组织不愿意将Linkerd部署到生产中，或者愿意为了这样做而不得不进行重大投资。这种摩擦是由下面几个因素引起的。
（更新的JVM显着改善了这些数字。在IBM的OpenJ9下，Linkerd 1.x的资源占用和尾部延迟大大减少，而Oracle的GraalVM承诺会进一步降低它。小声嘀咕：但这也改变不了第一条）
船新的开始
痛定思痛之后，Linkerd开始改变。定了几个目标：
最后在2018年9月他们推出了Linkerd2.0，六个月后，也就是2019年3月了，这种改变已经产生了回报，之前很多不愿意使用1.x的用户都接受了2.x。他们对Rust的选择引起了人们的极大兴趣。他们也承认，这是一种赌博，之前发布的早期产品叫「Conduit」，原因是害怕“玷污”了Linkerd的品牌（233），现在证明赌博是赌对了。从2017年开始，Linkerd团队对Rust网络库（Tokio、Tower和Hyper）进行了大量的投入（对Rust生态贡献很大）。
Wepoll是一个Windows平台的epoll API实现。
From 日报小组 @Chaos
日报订阅地址：
