这看起来雄心勃勃荒谬：
我们的目标是从头开始构建 SQLite 的重新实现，在语言和文件格式级别完全兼容，具有与 SQLite 相同或更高的可靠性，但具有完全的内存安全性，并且采用新的现代架构。
其背后的 Turso 团队已经维护他们的libSQL分支两年了，因此他们已经做好了应对如此大规模挑战的准备。
SQLite 以其细致的测试方法而闻名。 Limbo 计划采取一种基于“确定性模拟测试”的完全不同的方法，这是一种由 FoundationDB 首创的现代技术，现在由Antithesis牵头，该公司 Turso 一直在与他们之前的测试项目合作。
另一个大胆的主张（强调我的）：
我们将 DST 设施添加到数据库的核心，并与 Antithesis 合作，以实现数据库的可靠性水平，不辜负 SQLite 的声誉。
[…]通过 DST，我们相信我们可以实现比 SQLite 更高程度的稳健性，因为它更容易在模拟器中模拟不可能的场景，使用不同的事件顺序测试多年的执行，并在发现问题时重现它们100%可靠。
Limbo 计划提供的两个最有趣的功能是第一方 WASM 支持和完全异步 I/O：
SQLite 本身有一个同步接口，这意味着想要异步行为的驱动程序作者需要使用辅助线程，这会带来额外的复杂性。由于 SQLite 查询往往速度很快，并且不涉及网络往返，因此许多驱动程序只是满足于同步接口。 […]
Limbo 从一开始就被设计为异步的。它将
sqlite3_step（SQLite 的主要入口点 API）扩展为异步，允许它在数据未准备好立即使用时返回到调用者。
Datasette提供了一个用于执行 SQLite 查询的异步 API ，该查询由各种复杂的线程管理支持 – 我对用于与 SQLite 数据库文件通信的本机 asyncio Python 库非常感兴趣。
我成功地使用uv尝试了 Limbo 的Python 与演示 SQLite 测试数据库的绑定，如下所示：
uv run --with pylimbo python >>> import limbo >>> conn = limbo.connect("/tmp/demo.db") >>> cursor = conn.cursor() >>> print(cursor.execute("select * from foo").fetchall())
当我尝试使用包含 SQLite FTS 表的更复杂的 SQLite 数据库时，它崩溃了。
Python 绑定尚未记录，因此我通过LLM 管道传输它们，并让新的google-exp-1206模型为我编写了这个初始文档：
files-to-prompt limbo/bindings/python -c | llm -m gemini-exp-1206 -s 'write extensive usage documentation in markdown, including realistic usage examples'
通过黑客新闻
标签： rust 、 sqlite 、 uv 、开源、 python 、 llm
原文： https://simonwillison.net/2024/Dec/10/introducing-limbo/#atom-everything