Tokio alpha 版发布
#tokio
新版本支持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代码
#fullstack
这篇文章比较系统的介绍了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
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之后的感想
#cpp
文章不长,用作者的话来总结:与其把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)
#HKT
Read More: https://gist.github.com/edmundsmith/e09d5f473172066c0023ef84ee830cad
「系列文章」用Rust重写物联网网关 Part 3: Safe Rust 如何跳过C/Cpp的陷阱
#IoT
文章里这个类比比较经典(普罗米修斯盗了天火,为世界带来了光明,但与此同时也带来了灾难):
我们本可以用C++重写我们的物联网平台应用。使用C就像用蜡烛照明一样。它的基本属性是众所周知的,它从文明之初就存在了,如果你滥用它,它会让你周围的房子着火。(在这个比喻中,C++将是“所有可以被点燃产生光的东西的集合”。)
该文的作者是智能家居系统公司Dwelo的IoT工程师,该文主要罗列了一些Cpp编写嵌入式应用可能拥有的问题。
这篇文章为系列第三篇。
Cosmic: 多功能discord机器人
#discord
该项目是从Python到Rust的一个重写项目
Repo: https://github.com/Sreyas-Sreelal/Cosmic
「社区」Rust游戏工作组的调查
#Game
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进行了包装
#tokio
Docs: https://docs.rs/stubborn-io/0.1.3/stubborn_io/
可以将任何文件进行Hash然后生成一个甜甜圈图案
#wasm
由Rust和Wasm实现
- online demo: https://alugocp.github.io/donut/
- Repo: https://github.com/alugocp/donut
PodCast:采访Jimmy Cuadra
#podcast
话题关于Matrix,一个开放和分散的通信协议,以及他在Rust中的实现Ruma。该作者之前也出了视频课程,地址在这里:https://youtu.be/76BE1P8B1UU
Rust项目中如何在运行时重载配置
#reload
有些程序运行时间很长。对于这些,重启它们来改变配置不是你愿意做的事情。想象一个网络服务器或数据库服务器。这种东西总是处理大量的查询,重启会杀死所有当前正在执行的查询,这会导致最终用户出错,或者由于某些地方的重试而导致性能不佳。
作者的思考:
- 需要从一个或多个文件中加载配置
- 需要某种触发器来重新加载配置,然而,使用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
日报订阅地址:
独立日报订阅地址:
社区学习交流平台订阅:
评论区
写评论还没有评论