Rust 为什么不提供 HashMap 的 map 宏？

主要观点

• 历史遗留问题：作者表示从未真正理解为什么 Rust 没有提供 HashMap 的宏，并且自己多次编写过类似功能

现代解决方案

• collection macros 已经过时：由于现在每个集合都实现了 From<[T; N]> trait，collection 宏基本上已经不再必要

• 推荐的替代方法：使用 HashMap::from() 配合数组语法：

  let map = HashMap::from([
      (key1, value1),
      (key2, value2),
      (key3, value3),
  ]);
  

• 实践建议：作者通常在可能的情况下使用这种模式来替代宏

https://old.reddit.com/r/rust/comments/1s2ez82/why_doesnt_rust_provide_a_map_macro_for_hashmap/

VectorWare在GPU上实现Rust线程调度

VectorWare公司宣布成功在GPU上使用Rust的std::thread，这是朝着使用熟悉的Rust抽象来编写高性能GPU应用程序愿景迈出的重要一步。

核心要点

CPU与GPU的执行模型差异

• CPU程序从单线程开始，按需生成额外线程，程序员控制并发的时机和方式
• GPU程序由一个或多个内核组成，每个内核启动时会并行运行大量实例，并发是硬件运行方式固有的特性

GPU编程的挑战

• 大多数GPU编程模型使用函数作为入口点，但该函数会被硬件并行启动数千次
• 编程模型与执行模型之间的不匹配是GPU编程困难的部分原因
• 程序员需要手动维护正确的索引和避免竞态条件等不变量

Rust在GPU上的现状

• 当前GPU内核需要使用unsafe和原始指针，因为成千上万的实例同时运行并接收相同的指针
• 内核边界被视为FFI边界，没有编译器安全保证
• Rust的所有权模型是围绕CPU执行模型设计的，GPU执行模型对该语言来说是陌生的

VectorWare的目标

• 让GPU代码看起来像普通的Rust代码，能够与Rust生态系统原生集成
• 将Rust的安全保证扩展到GPU
• 避免创建需要学习新抽象的独立GPU编程模型

https://www.vectorware.com/blog/threads-on-gpu

Rust 移除 contains 方法引发的讨论

核心问题

Reddit 用户抱怨 Rust 移除了 Option 类型的 contains 方法，表达了对这一决定的不满。

主要观点

影响：

• 现在必须写更冗长的代码：my_option.is_some_and(|my_value| my_value == my_non_option_value)
• 原本可以用更简洁的 contains 方法

移除原因（据作者回忆）：

• 官方认为该方法是不必要的，因为他们稳定化了 is_some_and 方法

作者的反驳：

• 虽然可以用 my_option == Some(my_value) 来替代
• 但作者仍然认为 contains 方法可读性更好
• 不理解为什么要移除这个更符合人体工程学的方法

争议焦点

作者质疑移除 contains 方法的必要性，认为即使有替代方案，contains 依然是更易读、更符合直觉的 API 设计。

https://old.reddit.com/r/rust/comments/1s31jfu/i_really_hate_that_they_removed_the/

--

From 日报小组 Mike

社区学习交流平台订阅：

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