【Rust日报】 2019-08-12
Tokio alpha 版发布
新版本支持async/await
tokio = "=0.2.0-alpha.1"
#![feature(async_await)]
use tokio::net::TcpListener;
use tokio::prelude::*;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// ...
tokio::spawn(async move {
let mut buf = [0; 1024];
// ...
loop {
let n = match socket.read(&mut buf).await {
// ...
}
// ...
}
Read More: https://tokio.rs/blog/2019-08-alphas/
如何写全栈Rust代码
这篇文章比较系统的介绍了Yew、ws-rs（websocket）、serde等工具使用Rust编写一个Chat Web App。
Read More: https://www.steadylearner.com/blog/read/How-to-write-Full-Stack-Rust-code
gfx-rs标杆项目开启
gfx-rs并不是纯Rust编写。它依赖的一个复杂而重要的组件是用C和C++的混合语言编写的: SPRIV-Cross。它一个着色器翻译库，由 @TheMaister 和一些 Khronos 成员开发，虽然不是 Khronos 的官方产品，但需要它从SPIR-V源生成特定于平台的着色器。它有一个测试套件，它的后端主要由MoltenVK开发和使用。
SPRIV-Cross 在我们的性能报告中出现了很多次(例如在Dota2上)。它的编写方式也与惯用的Rust相去甚远: 代码更喜欢大的可变数据结构，这使得它很难模块化、测试、优化，尤其是在C/C++ FII之后进行交互。虽然它发展很快(就贡献而言)，但它在使用高级后端功能方面限定了我们可以做什么和不能做什么，例如内嵌、参数缓冲区等。它使我们的构建过程变得复杂，尤其是在需要单独的Emscripten构建(Rust代码不需要)来生成WASM模块的网络上，成为开发人员和用户的一个痛点。
所以，gfx-rs团队认为，是时候攻克gfx-rs中C++代码的最后一个堡垒了。标杆项目就是关于“飞出墙外的SPIR”（A SPIR that flies above the garden walls，意指，被扔出去了。。。）。这是一个非常复杂的软件，我们还没有取得很大进展。
然而，我们再次感到Rust是着色器翻译工作的最佳工具: 它是关于解析的，处理字节和数据结构，具有进行单元和模糊测试的能力，并且没有外部依赖性。
Read More: https://gfx-rs.github.io/2019/07/13/javelin.html
十年Cpp程序员学了三个月Rust之后的感想
文章不长，用作者的话来总结：与其把Rust看作是一门语言，倒不如将其看作是一个生态系统。他对Rust这个生态系统未来的成长感到非常excited。
- Facebook用Rust写区块链: Libra
- Goolge用Rust写操作系统: Fuchsia
- 亚马逊用Rust写虚拟化技术: FireCracker
- 微软推，崇业界都应该使用Rust语言。
看见了吗？ 四大巨头的未来主要核心业务都交给或准备交给Rust了。
这也是这个10年Cpp程序员开始学习Rust的原因：未来。
Read More: https://blog.aclysma.com/my-first-three-months-with-rust/
「跟进」Rust中模拟高阶类型（HKTs）
Read More: https://gist.github.com/edmundsmith/e09d5f473172066c0023ef84ee830cad
「系列文章」用Rust重写物联网网关 Part 3: Safe Rust 如何跳过C/Cpp的陷阱
文章里这个类比比较经典（普罗米修斯盗了天火，为世界带来了光明，但与此同时也带来了灾难）：
我们本可以用C++重写我们的物联网平台应用。使用C就像用蜡烛照明一样。它的基本属性是众所周知的，它从文明之初就存在了，如果你滥用它，它会让你周围的房子着火。(在这个比喻中，C++将是“所有可以被点燃产生光的东西的集合”。)
该文的作者是智能家居系统公司Dwelo的IoT工程师，该文主要罗列了一些Cpp编写嵌入式应用可能拥有的问题。
这篇文章为系列第三篇。
Cosmic： 多功能discord机器人
该项目是从Python到Rust的一个重写项目
Repo: https://github.com/Sreyas-Sreelal/Cosmic
「社区」Rust游戏工作组的调查
Rust游戏工作组是社区自愿发起的一个组织，这次他们发起调查，是为了更好地支持Rust游戏开发生态，游戏开发者们可以去参与。
Read More: https://users.rust-lang.org/t/survey-from-the-rust-game-development-working-group/31270?u=erlend_sh
stubborn-io： 对tokio的AsyncWrite/AsyncRead进行了包装
Docs: https://docs.rs/stubborn-io/0.1.3/stubborn_io/
可以将任何文件进行Hash然后生成一个甜甜圈图案
由Rust和Wasm实现
- online demo: https://alugocp.github.io/donut/
- Repo: https://github.com/alugocp/donut
PodCast：采访Jimmy Cuadra
话题关于Matrix，一个开放和分散的通信协议，以及他在Rust中的实现Ruma。该作者之前也出了视频课程，地址在这里：https://youtu.be/76BE1P8B1UU
Rust项目中如何在运行时重载配置
有些程序运行时间很长。对于这些，重启它们来改变配置不是你愿意做的事情。想象一个网络服务器或数据库服务器。这种东西总是处理大量的查询，重启会杀死所有当前正在执行的查询，这会导致最终用户出错，或者由于某些地方的重试而导致性能不佳。
作者的思考：
- 需要从一个或多个文件中加载配置
- 需要某种触发器来重新加载配置，然而，使用inotify之类的工具监视配置文件更改的做法不是最佳实践
- 需要一个手动触发器
- unix守护进程约定是向进程发送一个SIGHUP信号，对于命令行应用程序，此信号意味着终端消失了，你可能想要终止它。unix守护进程没有终端，所以它被重用了。在SIGHUP上，守护程序通常会重新加载其所有配置并重新打开日志文件(这是为了与logrotate集成)
- 推荐使用signal-hook来侦听信号，因为信号一般很容易被错误使用，这个库屏蔽了信号使用的大部分问题。
- 或者，程序可以通过某种方式发送一些触发重载的RPC命令
- 配置文件有三种应用场景：初始化/ 每次都需要加载/ 需要主动更改的配置
根据上面的思考，作者开发了Spirit框架。但是该框架还有很多工作要完善。
（目测该框架会对Rust在自动化运维方向起到促进作用）
- Reddit 讨论： https://www.reddit.com/r/rust/comments/couwju/runtime_configuration_reloading/
- 原文： https://vorner.github.io/2019/08/11/runtime-configuration-reloading.html
- signal-hook https://crates.io/crates/signal-hook
- Spirit: https://github.com/vorner/spirit
From 日报小组 Chaos
日报订阅地址：
独立日报订阅地址：
社区学习交流平台订阅：