【Rust日报】Ratatui 支持 no_std 环境、引入 Flex 布局系统-平芜编程栈

Ratatui 发布 v0.30：支持 no_std 环境、引入 Flex 布局系统

Ratatui v0.30是该库演进中的重要里程碑，其核心突破是实现了对no_std环境的基础支持。通过将核心逻辑与 Rust 标准库解耦，Ratatui 现在可以在嵌入式系统、固件及受限的 WASM 环境中运行，极大地扩展了终端 UI 在非桌面场景下的应用边界。

在功能层面，该版本引入了革命性的 Flex 布局系统。借鉴 CSS Flexbox 逻辑，开发者利用Layout::flex即可轻松实现组件的比例分配、对齐及间距控制，显著降低了构建复杂响应式界面的难度。

在开发者体验（DX）方面，v0.30 进行了重大 API 简化：Frame结构体移除了对Backend的泛型依赖。这使得函数签名更加简洁，消除了大量样板代码。此外，新增的Constraint::Fill约束让布局能更智能地填充剩余空间。

其他更新还包括：增强的滚动条（Scrollbar）交互、更精细的文本折行控制以及对Color类型的优化。

v0.30 通过no_std带来的极致便携性与 Flex 布局带来的开发效率提升，标志着 Ratatui 正式从一个基础绘图工具进化为功能完备、全平台适配的现代化 UI 框架**。

阅读：https://ratatui.rs/highlights/v030/

PicoRDM：Redis 终端管理器

PicoRDM是一款基于Rust编写的轻量级Redis 终端 UI (TUI) 管理工具，旨在作为重量级 GUI 客户端（如 RedisInsight）的极简替代方案。

极简高效：利用 Ratatui 框架构建，二进制文件仅约 2MB，启动极速且内存占用极低。功能完备：支持多连接管理（含 TLS）、Key 实时搜索与批量处理、服务器状态监控（内存/连接数等）以及集成的原生 CLI 交互模式。交互友好：提供丰富的快捷键支持并兼容鼠标操作，支持通过剪贴板快速导入连接字符串。跨平台：原生支持 Windows、macOS 和 Linux。

仓库：https://github.com/osdodo/picordm

lisp-in-types：用 Rust Trait System 实现的 Lisp 求值器

作者完全利用 Rust 的类型系统（通过 Trait 编程）实现了一个 Lisp 解释器。这意味着所有的计算都在编译期完成，而不是在程序运行时。

初衷：作者提到是因为“太无聊了”，所以决定挑战 Rust 类型系统的极限。尽管是在类型系统中实现的，该项目的功能却出奇地完整：

基础语法：支持defun（定义函数）、let（局部变量）、begin（顺序执行）和apply。
高级特性：甚至支持限定延续（Delimited Continuations），通过call/ec实现。
数值计算：目前默认支持 0 到 8124 的数字。

技术细节与局限：

编译器负担：由于复杂的类型递归计算，运行该项目通常需要增加rustc的堆栈大小。
可扩展性：作者在build.rs中生成了数字定义，用户可以修改它来支持更大的数字范围，但代价是编译时间和内存消耗会激增。
计算模型：这证明了 Rust 的 Trait 系统是图灵完备的，可以用来编写复杂的逻辑，尽管这并不是它的设计初衷。

仓库：https://github.com/playX18/lisp-in-types/

讨论：基于完成的异步 IO 模式

如何在 Rust 中以优雅且高性能的方式建模“基于完成”（Completion-based）的异步 I/O 模式（如io_uring），以及 Rust 现有的异步生态对此支持的局限性。

核心背景：极致性能的追求楼主（servermeta_net）正在开发一个基于io_uring的高性能 Web 服务器，目标是利用 Linux 内核 6.12+ 的最新特性实现零拷贝、零分配。

惊人的数据：楼主声称其原型在 4 核环境下达到了 7000 万+ RPS（32 字节请求）和 20Gbps 的带宽（尽管社区对其准确性有争议，但这反映了io_uring的巨大潜力）。
技术栈：使用了io_uring（多扇区接收、批处理）、kTLS（内核态加密）、零拷贝缓冲区管理。

面临的技术痛点尽管性能极高，但楼主遇到了“Rust 风格”建模的难题：

状态机 vs Future：目前使用自定义状态机来管理请求，虽高效但难以编写和维护。楼主想知道如何将其转换为标准的async/await语法。
缓冲区所有权：在“基于完成”的模型中，内核在 I/O 完成前拥有缓冲区的所有权。这与 Rust 传统的AsyncRead/AsyncWrite（基于“就绪”/Readiness 模式，用户拥有缓冲区）冲突，导致楼主不得不大量使用unsafe代码。
生命周期与取消：当一个异步操作被取消时，必须确保内核不再访问该内存，否则会发生内存损坏，这在 Rust 的poll模型下极难安全实现。

对现有框架的评述讨论中深度剖析了现有 Rust 异步库在处理io_uring时的短板：

Tokio：被认为“根基上就是错的”。因为 Tokio 是为epoll（基于就绪通知）设计的，将io_uring强行塞入 Tokio 会导致跨线程传递 Ring 等不符合底层设计的做法，且无法发挥io_uring的批处理优势。
Monoio / Compio / Glommio：这些库虽然比 Tokio 更贴近io_uring，但仍被认为存在局限。例如 Monoio 依赖的底层库版本较旧，Compio 为了跨平台（Windows/Linux）在性能和特性上做了妥协。
推荐关注：axboe-uring（更接近原作者 liburing 的实现）、ringolo、以及without.boats关于io_uring的深度解析博客。

社区核心观点与建议

所有权是关键：在io_uring中，Future 必须在操作期间“租借”或“锁定”缓冲区所有权。现有的AsyncRead接口已不适用，社区正在探索新的Completion驱动接口。
批处理的力量：楼主强调，io_uring的真正性能提升来自于“批处理提交/完成”以及减少内存屏障（Memory Fences），而目前的通用异步运行时往往在每个操作上都消耗了过多开销。
不成熟的现状：大家公认 Rust 目前的异步标准（基于poll的 readiness 模型）与现代硬件/内核趋势（completion 模型）存在根本性不兼容，这可能需要 Rust 在编译器或标准库层面引入新的异步原语才能完美解决。

总结结论：这是一个关于“底层性能极限”与“高级语言抽象”之间冲突的讨论。它揭示了即便是在 Rust 中，想要在不牺牲安全性的前提下发挥io_uring的全部威力，仍然是一个尚未被完全攻克的难题。

Reddit：https://www.reddit.com/r/rust/comments/1ptw1sk/modeling_modern_completion_based_io_in_rust/

From 日报小组苦瓜小仔

社区学习交流平台订阅：