一张图列出 20 个 Rust 数据库项目
这是一张把 20 个数据库项目围在 Rust 标志周围的图。Low_Brilliant_2597 2026 年 10 月 19 日把它发到 r/rust。采集时 722 分、143 条评论。帖子没有外部文章，原文就是这张图。
图的标题是 The Growing Ecosystem of Database Systems，副标题是 Built on Rust。中间是一个带 R 的齿轮。20 个项目标志用灰线连到中间。RisingWave 单独放在白底圆角框里。图上没有数字，也没有分类标注。
上排从左到右：Apache DataFusion、Neon、RisingWave、GreptimeDB、SurrealDB。左侧从上到下：Polars、ParadeDB、HelixDB、LanceDB、Qdrant。右侧从上到下：slatedb、Databend、turbopuffer、Turso、TiKV。下排从左到右：SmithDB、HydraDB、readyset、SedonaDB、influxdb。
评论里 dgkimpton（342 分）写，自己会继续用 Postgres，除非某个具体场景逼着换；要紧的是可靠性。TheLexoPlexx（167 分）写，图上这些项目都在卖托管云，功能比自托管版多；Postgres 就是 Postgres，再加上插件。mark-haus（61 分）写，Postgres 覆盖面广，本地连接、少运维可以看 SQLite，多数项目可以先从这两个开始。Hunter_Affectionate（18 分）写，图上列出的库面向 OLAP 或向量检索，举的例子是 Qdrant，并认为拿它们和 Postgres 比类别不同。f311a（28 分）写，它们各自对着具体场景，并不和 Postgres 竞争。Floppie7th（30 分）写，有选项这件事本身算不上麻烦。
原文链接：https://www.reddit.com/r/rust/comments/1x9rg9l/the_growing_ecosystem_of_rustbased_database/
Rust 编译器多项长期投入开始见到结果
这是一篇 Rust 编译器年度盘点。panstromek 2026 年 10 月 19 日把它发到 r/rust。采集时 208 分、6 条评论。文章末尾给出 GitHub Sponsors：https://github.com/sponsors/panstromek 。
文章写，多项长期投入在 2026 年同时走到后面的阶段，并开始看到结果。作者写，这一年的工作量本身并不比往年更大。
作者把下一代 trait solver 放在第一位。文章写，它重写类型系统的一大块，各种形式加起来接近 10 年，修一批健全性错误，并解开 async Rust 和 impl Trait 上的一批长期限制。Polonius 是另一项借用检查实现，能让更多代码通过编译。文章写，它还可能解开内部引用，时间不确定；对编译器的影响小于新 solver。
性能方面，并行前端接近稳定，项目目标由 petrochenkov 推进。停了几年后重新开始，SparrowLi 先加入，后来又有其他人。作者写，自己的感觉是几乎没有人真正满意这个设计，眼下也没有更好的替代，所以是把具体问题磨完。LLVM 23 的性能变化是明确正向。LLVM 10 升级曾经带来大约 10% 回退。LLVM 22 在 icount 上是绿的，wall time 上几乎全是红的。文章写，LLVM 23 基本全是正向。
Amanieu 提议的 MIR move elimination 去掉 LLVM 难以优化的拷贝，编译时间和运行时间都会变快。文章写，这一步放在 MIR，因为 Rust 侧知道这次消除对 Rust 是否合法，而且需要改一点 MIR 语义。Rust 生成的 move 比 C 和 C++ 多。camelid 推进的 polymorphization 仍是实验。文章写，原先的做法只避免重复单态化；这一次受 Swift 启发，把泛型参数的布局当参数传下去，有运行时成本，可以用编译器旗标调节。
blyxyas 在做 cargo check 和 cargo build 共享产物。文章写，这件事已经宣布，target 目录体积会缩小 5% 到 30%，看工作负载。新的 cargo build-dir 布局也已宣布，文章写它解开 target 目录的细粒度锁和跨 workspace 缓存。bjorn3 在修 no-link 和 link-only，用来把 build script 和 proc macro 流水线化。
架构上，jdonszelmann 两年前开始统一属性的表示和检查，文章写几天前最后一个属性迁到新系统。Zalathar 和 nnethercote 清理了 query system 的实现。项目目标方面，文章写现在有 Fast Builds 路线图。Maintainers in Residence 于 2026 年 8 月 26 日宣布。作者还写到 Hexcat 过去一年雇了一批人。作者自己加入过 perf triage，申请了 MiR，并同意在有资金时做 target 目录体积缩减。作者写，MiR 资金有限，自己不认为很快能排上。
评论里 termhn（16 分）写，自己平时跟得比较紧，文章里大约一半之前不知道。kibwen（8 分）写，这是一份清楚的总览。
原文链接：https://yoyo-code.com/2026-is-exciting-year-for-rust-compiler-and-me/
Ante 用 place 做零成本循环可变
这是 Ante 的一篇借用检查文章，讲如何用 place 做零成本的循环可变。RndmPrsn11 2026 年 10 月 19 日把它发到 r/rust。采集时 84 分、17 条评论。文章日期是 2026 年 10 月 19 日。
Ante 是带所有权和借用的低层函数式语言，仓库在 https://github.com/jfecher/ante ，许可证 MIT。采集时 GitHub 有 2357 个 star，最近推送时间是 2026 年 10 月 19 日。文章写，Ante 想放宽“可以别名，或者可以修改，不能同时”这条规则，同时仍静态拒绝悬垂指针。新设计把 group borrowing 和作者自己的想法合在一起。
文章用 place 代替 lifetime。place 是引用可能借自的那一组具体位置，可以是变量、字段路径，或几个来源的并集。不稳定的 place 写成 !。对 a! 的引用会在修改 a 时失效。Vec.first_mut 和 Vec.last_mut 返回 mut 'v! t。文章写，这样可以同时拿出第一个和最后一个元素再改其中一个，因为这次修改只会使 v!! 失效，而这两个引用的 place 是 v!。
循环可变用带 place 参数的 Rc 'p t。Rc.get 返回的内部引用同时带上外层不稳定 place 和共享 place。文章给出一个把链表尾指回前面节点的例子，遍历 5 步会交替打出 true 和 false。文章写，这和 Rust 里的 GhostCell 类似，检查全是静态的，不需要 GhostToken，也没有运行时检查。脚注写，用 Rc 组成循环仍然会泄漏，回收是另一件事。上一版设计在遍历时要克隆一些 Rc；文章写，新设计不再需要这些克隆。
线程安全沿用 Send 和 Sync。ref 和 mut 允许共享可变，两个 trait 都不实现。imm 和 uniq 对应 Rust 的 & 和 &mut。文章写，这两种引用很少用，主要出现在跨线程之后再降回 ref / mut。
评论里 Accomplished_Item_86（26 分）写，Valen 的 group borrowing、Mojo 和 Zeta 也在用一组可能来源跟踪失效或不相交，Ante 把这组来源叫 place。RndmPrsn11（15 分）回复，Carbon 也在往这个方向走。panstromek（9 分）问，新的部分到底是什么，因为 Polonius 已经在用接近 place 的模型。作者回复，自己原先以为把 lifetime 做成 place 是 Polonius 之外的工作，回头看原来的 Polonius 文章后认为这个判断不对；文章的主要部分仍是零成本循环可变。
原文链接：https://antelang.org/blog/safe_cyclic_mutability/
mbrotli 把压缩任务交回调用方
这是 Brotli 压缩库 mbrotli 的一篇设计说明，讲库如何把并行任务交回调用方。Mnwamnowich 2026 年 10 月 19 日发在 r/rust。采集时 47 分、26 条评论。
mbrotli 是安全 Rust 写的 Brotli 压缩库，仓库在 https://github.com/M-Compressors/mbrotli ，许可证 Apache-2.0。采集时 GitHub 有 21 个 star，最近推送时间是 2026 年 10 月 19 日。crates.io 当前版本是 0.5.16，总下载 1615 次。crate 说明写，编码结果与 Google 参考编码器逐字节相同，覆盖 RFC 7932 和 RFC 9841。
帖子写，库知道怎么把压缩拆开，执行交给调用方。ParallelCompressor::writer 返回写入端和任务队列。例子用 std::thread::scope 起 4 个线程，每个线程从队列里取任务并调用 task.run()。库自己不起线程。调用方要保证任务真的被执行。作者写，调度器设计得不好时容易死锁。作者写，低层库把调度权交出去，对已经有线程池的程序更合适；也写了，有些库自己管线程仍然合理。
评论里 aelgorn（27 分）写，库如果把并行能力暴露给调用方，调用方就能避开和硬件或场景不匹配的假设。作者（8 分）写，项目里常常已经有 rayon 或 tokio 的 spawn_blocking，库再起一套线程会碍事。flareflo（4 分）建议提供兼容 rayon 的迭代器，让调用方自己选择是否并行。
原文链接：https://www.reddit.com/r/rust/comments/1x9u5vw/some_thoughts_on_parallelism_in_libraries_who/
From Rust中文社区 Mike
社区学习交流平台订阅：
评论区
写评论还没有评论