Wasmtime 47 默认启用 Wasm GC 与异常支持：高阶语言进军 WebAssembly 又少了一层自带运行时包袱

Bytecode Alliance 这次放出的信号很强：Wasm GC 和 异常处理（exceptions） 已经在 Wasmtime 47 中默认开启。对 WebAssembly 生态来说，这不是单纯“多支持两个 proposal”，而是意味着更多高阶语言终于可以更自然地把对象模型、引用类型和异常机制直接带进 Wasm，而不必再在 .wasm 包里自带一套沉重的垃圾回收器或手搓异常调用约定。

文章把这两条能力讲得很透。GC 这一侧，Wasm 程序可以直接定义自己的 struct / array 类型和子类型关系，让运行时负责对象生命周期；异常这一侧，则不必再让每个函数额外返回“是否抛错”的状态位，能把 try/catch 风格重新交回给运行时实现。这两件事叠在一起，带来的不只是模型更优雅，也会直接影响 二进制体积、正常路径运行开销以及语言接入 Wasm 的工程复杂度。

更值得 Rust 社区关注的是 Wasmtime 自己的实现路线。团队没有把 GC 做成一层脱离现有架构的特例，而是用 Cheney 风格半空间复制 GC，并把 GC heap 建在 WebAssembly 线性内存之上，继续吃到 Wasmtime 已有的安全、可移植和虚拟内存护栏能力。再配合针对 Wasm GC 扩展过的 fuzzing 基建，这次默认启用更像是“多年工程收口后的里程碑”，而不是实验性开关。对做运行时、编译器、Wasm 平台的人来说，这条线的长期影响会比单次版本更新大得多。

原文链接：https://bytecodealliance.org/articles/wasmtime-gc

Syn 3.0.0 发布：Rust 宏解析事实标准库为新语法和未来 RFC 预留出更大空间

syn 3.0.0 的份量，不在于“又发了个大版本”，而在于它更新的是 Rust 生态里最基础也最容易被忽视的一层：宏与语法树解析基础设施。过去三年 Rust 语言本身一直在持续演进，而 syn 这次把大量已经落地、正在推进、以及需要提前留接口空间的语法变化统一吸收进来，等于是在为整个 procedural macro 生态做一次底座级升级。

这版 release notes 最醒目的点，是为了给未来语言发展留足余量，新增了一批 非穷举的 *Modifiers 结构，把原本容易被写死的语法位置改成“允许未来扩展但当前默认无 token”的设计。与此同时，类型、表达式、pattern、item、generics 等多块 AST 也都有实质性调整：像 Type::BareFn 改名成 Type::FnPtr、Arm 的 guard 改由新的 Pat::Guard 承载、类型和 where 谓词上的 attributes 保留得更完整，都是会波及大量宏工具链的真实变化。

换句话说，syn 3.0 不是那种“表面版本号很大、实则只是清理 API”的版本，而是一次面向未来 Rust 语法形态的系统性整队。对维护 derive 宏、代码生成器、静态分析工具或者 DSL 的开发者来说，这类升级往往比普通应用层库更新更关键，因为它直接决定你能不能稳稳接住接下来几轮语言演进。

原文链接：https://github.com/dtolnay/syn/releases/tag/3.0.0

mmap behind the scenes in a database：Append-only 数据库为什么反而适合把页缓存交给内核

这篇长文的价值，在于它不是泛泛而谈“mmap 好不好”，而是把争议重新放回具体数据库模型里讨论。作者过去几年一直在做 TB 级 append-only 数据库，核心观点很鲜明：如果你的存储段在 seal 之后就是只读不可变文件，那么很多传统数据库里让 mmap 挨骂的问题，根本就不是同一个问题。

文章把这件事拆得很细。对 append-only 引擎来说，查询阶段面对的是已经落盘、不会原地修改的 segment；新写入数据靠普通文件 I/O 和 WAL 保证；而 mmap 只负责把这些只读 segment 映射进来，让随机访问直接站在 内核 page cache 之上。这样做的直接好处是：热页保留、冷页回收、缺页再拉回，全部交给操作系统处理，应用层不必再自己发明一套页级缓存淘汰策略。

更重要的是，它顺手把一个经常被混在一起的概念讲清了：文件映射页 和 匿名内存 的回收成本完全不同。只读 mmap 背后的 file-backed page 在内存紧张时可以被内核直接丢弃，之后按需再 fault 回来；但查询执行时自己在堆上建出来的 hash table、buffer、临时结果集，依旧是应用必须严控的 anonymous memory。也就是说，mmap 不是“数据库内存管理万能药”，但对于 immutable segment 这条线，它确实能把一大块复杂度安全地下放给内核。这种把争论从口号拉回 workload 形状本身的写法，很值得做存储和系统的人细看。

原文链接：https://savannahar68.medium.com/mmap-behind-the-scenes-in-a-database-263186dda699