Rust Infra 团队：清理 GitHub Rust 组织成员

• 成员清理情况：基础设施团队正在清理由 Rust 项目管理的 GitHub 组织（包括 rust-lang、rust-dev-tools、rust-lang-deprecated、rust-lang-nursery 和 rust-analyzer），移除那些在这些组织中不属于任何团队的成员。活跃的 Rust 团队成员不用担心，其对 rust-lang 组织的访问权限不受影响，最多只会从一些不再活跃使用的遗留组织中被移除。
• 对非活跃贡献者的处理：如果曾为 Rust 做出贡献但目前已不再活跃，那么很可能会从所有提到的 GitHub 组织中被移除。不过，贡献者身份会在 Rust 官网的团队页面上显示，其中包含每个团队的校友部分。如果过往的团队归属未在该页面上体现，可进行联系。并且，他们也感谢过去为 Rust 做出贡献的人，使其成为如今的样子。
• 沟通渠道：如果被从认为应该属于的组织中移除，或者有其他疑问，可在 Zulip 平台上与他们联系。
• 归档团队成员的特殊情况：不幸的是，归档团队不会在网站的治理页面上显示，因此只属于归档团队的前 Rust 项目成员不会被列入任何校友部分。他们创建了一个 GitHub 问题来跟踪此事，同时在文中感谢了这些贡献者，并列举了部分人员名单。

Rxtui：可组合的响应式 TUI 框架

我中途放弃了我的终端聊天应用程序，而是构建了一个 TUI 框架。

我正在开发一个终端聊天应用。应该很简单，消息、输入框、用户列表。标准的东西。然后我遇到了所有 TUI 应用都会遇到的问题：你什么都写不了。想要一个可重复使用的消息气泡？太糟糕了。你每次都得手动计算矩形坐标。想要包裹元素？数学作业。想要居中？又是数学题。想要真正嵌套的独立组件？那就把同样的渲染代码复制粘贴到各处，祈祷它能正常工作吧。经过几天的苦苦挣扎之后，我愤怒地退出并建立了 rxtui。

#[derive(Component)]
struct MessageBubble {
    user: String,
    message: String,
}

impl MessageBubble {
    #[view]
    fn view(&self, ctx: &Context, message: String) -> Node {
        node! {
            div(border: rounded, pad: 1, gap: 1) [
                vstack(justify: space_between) [
                    text(&self.user, bold, color: cyan),
                    text(&self.message, color: white)
                ],
                // ...
            ]
        }
    }
}

这是一个真正可复用的组件。可以在任何地方使用它：

node! {
    div(overflow: scroll) [
        node(Header { title: "Chat" }),
        div(align: right) [
            node(MessageBubble { user: "bob", message: "hi" }),
            node(MessageBubble { user: "alice", message: "hello" }),
        ]
    ]
}

无需坐标计算，无需手动绘制矩形。组件真正组合。

现有的 TUI 库最让我头疼的是什么？你 90% 的时间都花在布局引擎上，而不是在开发应用。计算偏移量，管理坐标，然后第 10 次从头开始重新构建滚动。

使用 rxtui，您只需编写组件。弹性框式布局。内置滚动和焦点功能。自动调整大小。这些基本功能应该成为 2024 年的必备功能。

如果您曾经想在终端应用程序中只编写 div(align: center) 而不是像 1985 年那样计算中心坐标，那么这适合您。

虽然还为时过早，但我正在把它用于真正的工具。

仓库：http://github.com/microsandbox/rxtui

Reddit：https://www.reddit.com/r/rust/comments/1n0q464/media_i_abandoned_my_terminal_chat_app_halfway/

讨论：Rust 在 const eval 方面落后 Zig 多少？

“Zig comptime 的目标有所不同，因为它也用于反射和泛型。Const fns 最初没有基于反射的目标（尽管有一个工作组专门负责此事），而且他们特意表示它不会像 comptime 那样松懈。另一个问题是，稍后将 const eval 添加到编译器并非易事。Zig 的优势在于在设计时就考虑到了 comptime。”

“我不同意“稍后向编译器添加 const eval 并不是一件容易的事”。编译器已经有一个 const eval 解释器，可以运行任何 Rust 代码。这不是实现问题，纯粹是 API 设计的规范问题，让库作者可以说“这保证是 const 可求值的”。 Miri 的工具其实就是对 const-eval 解释器的重新包装。”

Reddit：https://www.reddit.com/r/rust/comments/1mzyo79/how_far_is_rust_lagging_zig_regarding_const_eval/

--

From 日报小组 苦瓜小仔

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区