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 日报小组 苦瓜小仔
社区学习交流平台订阅：
评论区
写评论还没有评论